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PREFACE 


The National Airspace Data Interchange Network (NADIN) is being developed, in its 
initial phases, as a common data communications network that will integrate various FAA 
communications services, specifically those involved in the exchange of information 
pertaining to air traffic control. The initial design was specifically directed to the 
absorption of the Aeronautical Fixed Telecommunication Network (AFTN), NASNET, and 
most of Service B. The design also provided for the expansion of NADIN facilities and 
circuits so as to accommodate growth, both in terms of requirements for included services 
and in terms of additional services. 

Concurrently with efforts to implement the initial NADIN design, efforts have been 
directed to the analysis of other services that might be integrated into NADIN. These 
analyses have two major objectives. First they are to determine if the integration of the 
specific service into NADIN is cost/benefieial. Second, they are to determine the specific 
enhancements to NADIN that would be required to absorb that service. These efforts have 
already led to the specification of an enhanced NADIN, referred to as NADIN IA, which also 
includes communications support for the Flight Service Automation System (FSAS), Flight 
Data Input/Output (FDIO) equipment, Automated Flow Control (AFC) and the National 
Flight Data Center Information System (NFDC/IS). Current FAA plans call for the 
implementation of NADIN IA in 1983. 

Studies of further possible enhancements are continuing. This report documents such 
an analysis conducted with respect to the Computer B (NAS-NAS) service. 
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SECTION 1 


INTRODUCTION 


1.1 SUMMARY OF RESULTS 

Enhancement of the National Airspace Data Interchange Network (NADIN) to provide 
effective support for Computer B (NAS-NAS) communications is feasible and cost-effective. 

This is the major finding from the comparative analysis of alternative approaches to 
NAS-NAS communications support. This and other related findings have led to the following 
conclusions: 

Conclusion 1: NAS-NAS communications should be incorporated into NADIN before 

the NAS 9020 computers are replaced. 

The architecture of the current Computer B (NAS-NAS) Network would have to be 
significantly altered in order to facilitate replacement of enroute computers (expected 
about 1988) and to support other planned modifications to the enroute computer system. In 
comparison, NADIN, which can be enhanced to meet NAS-NAS requirements, includes in its 
basic design features more compatable with the requirements of those long-range plans for 
computer system modification. 

Conclusion 2 : If NADIN is to support NAS-NAS communications, the NADIN 

architecture should be enhanced so as to provide virtual circuits and alternate routing 
capabilities based on packet-switching technology. 

This approach, although involving more modifications and greater cost than the other 
enhancements to NADIN considered, provides greater benefits, not just with respect to the 
NAS-NAS service, but also with respect to longer range plans for computer system 
modifiction and NADIN evolution. 


1-1 





r * 


Conclusion 3 : Enhancements to the NADIN architecture to incorporate packet¬ 

switching technology should reflect a broader range of requirements than just those 
associated with the NAS-NAS service. 

The suggested enhancements to the NADIN architecture will facilitate the support of 
a number of FAA communications requirements in addition to the NAS-NAS service. 
Greater efficiency would thus be achieved by implementing an integrated enhancements 
package, optimized to support as many of those requirements as practical. Since the 
NAS-NAS Network currently performs in a completely satisfactory manner, reasonable 
delays to develop and implement such an integrated enhancements package can be tolerated. 

1.2 PURPOSE AND SCOPE 


Under FAA Contract DOT-FA79WA-4355, Network Analysis Corporation (NAC) is 
investigating the feasibility and technical approaches for enhancing NADIN to incorporate a 
variety of communications services not included as part of the initial implementation. 
Results of earlier efforts under that contract have already been reflected in the specifica¬ 
tions for the first enhancements to NADIN (NADIN IA). 

Task 2 of the contract addressed the Computer B (NAS-NAS) service. It determined 
the most cost/beneficial approach to the support of NAS-NAS communications, considering 
the current Computer B (NAS-NAS) Network and various enhancements to NADIN IA. This 
report documents that study and its results. 

In order to establish a baseline of costs and benefits that would result from including 
various services within NADIN, each service is being considered separately during the initial 
phases of the contract. Thus this task (Task 2) considered the possible enhancement of 
NADIN IA to incorporate the NAS-NAS service with minimal regard to other possible 
service additions. Further, it considers only subjectively the impact of the ATC Computer 
Replacement Program (CRP) and the Advanced Enroute Automation (AERA) Program. The 
results of Task 2 and other tasks related to individual communications services will, 
however, serve as major inputs for three broader tasks under the contract: 

• Tasks 12 and 14, which address communications support for the Computer 
Replacement Program, and 

• Task 13, which addresses the integration of the individual service requirements 
and proposed enhancements. 
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1.3 BACKGROUND 


The National Airspace System (NAS) requires an intercenter computer communications 
subsystem for the fast, accurate and reliable exchange of flight plans and track data. This 
communications service is currently provided by the Computer B (NAS-NAS) Network. That 
network is a collection of point-to-point circuits between the NAS 9020 computer complexes 
located at neighboring Air Route Traffic Control Centers (ARTCCs). 

The NAS-NAS Network performs in a highly acceptable manner, at a cost that is high 
but not unreasonable. Although this network should be able to provide high quality service 
indefinitely, broader FAA concerns suggest that it might be beneficial to provide the 
NAS-NAS service through a more flexible, common network, such as NADIN. 

1.3.1 NAS-NAS Network Limitations 


As suggestd above, there are no limitations associated with the performance of the 
NAS-NAS Network. The NAS-NAS service does, however, impact on other areas of FAA 
interest. These broader concerns reveal limitations in terms of cost, NAS 9020 communica¬ 
tions overhead and interconnection flexibility. 

1. Cost ; The major concern of FAA is air safety. Cost must thus be a lessor 
concern when considering enhancements to the Air Traffic Control (ATC) 
System. Nevertheless, cost efficiency is always desirable, especially in light of 
the current tight government budget and the continuing cost increases for 
communications facilities. 

The current NAS-NAS Network employs dedicated, redundant communications 
links, with capacity far in excess of that required, even considering projected air 
traffic growth to the end of the decade. The annual cost of this service is 
currently about $500,000. Significant savings should be possible, without 
significant service degradation, through the sharing of communications 
resources. 

2. NAS 9020 Communications Overhead : The NAS-NAS Network requires four 
NAS 9020 adaptor ports at each end of a link between two ARTCCs. As a result 
up to 28 such ports are required at one NAS 9020 complex just for the NAS-NAS 
service. In addition, the NAS-NAS Network requires that the NAS 9020 





computers perform essentially all associated communications functions, 
functions that can generally be performed more efficiently by specialized 
communications equipment. 

These requirements on 9020 resources are not excessive, even when considered in 
combination with similar requirements for other communications services 
terminating at the 9020 computer. However, the projected growth in air traffic 
together with the associated need to automate more ATC functions would strain 
the capacity and capabilities of the 9020 computers in the next decade. In light 
of this, FAA has initiated the ATC Computer Replacement Program, directed 
toward the replacement of the 9020s starting about 1988. 

Possible reduction of NAS-NAS communications requirements on the 9020 would 
be beneficial from two aspects. First, any reduction in such requirements would 
increase the capacity of the 9020 for new functions prior to computer 
replacement. Second, at the time of computer replacement, switch-over and 
testing would be greatly facilitated if the number of individual interfaces to the 
computers were reduced. 

Incorporation of the NAS-NAS service into a common network such as NADIN 
could significantly reduce the number of interfaces required. The potential 
would also exist to reduce the communications functions performed by the 9020. 
Utilizing this latter potential would require major modifications to the NAS 9020 
software and should be avoided unless computer capacity becomes strained prior 
to replacement of the NAS 9020s. Use of a common network for NAS-NAS 
communications could thus serve as a near-term hedge and a longer range 
transition facilitator. 

Interconnection Flexibility : Although the NAS-NAS Network has a highly 
connected topology, direct communications is only provided between designated 
ARTCCs, generally those that are adjacent. Any use of the network for indirect 
routing of messages requires the inclusion of switching functions in the 9020 
software and places a greater processing load on the 9020 computer. This 
approach has been employed at selected ARTCCs to relay flight data from more 
remote ARTCCs to the Jacksonville computer complex, to aid in flow control. 








NAS-NAS communications between centers that are not directly linked by the 
current network, although not currently required, will be required by the end of 
the decade. Following replacement of the NAS 9020s, a major program (AERA) 
to increase automation of enroute ATC functions is to be implemented. The 
degree of automation anticipated makes it essential that there be no significant 
break in automated functions, even if an entire center is lost (e.g., as a result of 
an earthquake). Various concepts are being studied by FAA to provide for such 
contingencies. These generally involve the use of the ATC computers at one or 
more neighboring centers to back up an inoperative ATC computer. Each ATC 
computer must thus be able to exchange NAS-NAS messages with the same 
computers as the one(s) it is designated to back up. 

In order to provide such flexibility in the NAS-NAS Network, each ATC 
computer would have to act as a message switch or there would have to be a 
major increase in the number and miles of dedicated NAS-NAS links. A common 
network would not be so limited. NADIN, with its centralized switches and the 
ability of one switch to back up the other, already provides for inter¬ 
communications between all ATC computers. A less centralized topology would, 
however, serve this function more effectively. 

1.3.2 NADIN Limitations 


Use of NADIN to support NAS-NAS communications can overcome the above 
limitations of the NAS-NAS Network. Initial NADIN and its first enhancement (NADIN I A), 
although designed to provide high level performance, have limitations with respect to 
supporting the NAS-NAS service. These relate to network delays and back-up service. 

1. Network Delays . The point-to-point, dedicated links of the NAS-NAS Network 
result in almost no network delay. Use of NADIN, on the other hand, would 
require NAS-NAS traffic to contend with other message traffic for use of the 
links. Additional delays are introduced by processing at the concentrators and 
switches. Although the specifications for initial NADIN and NADIN IA call for 
average end-to-end delays of less than two seconds, this is not felt to be 
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satisfactory for NAS-NAS traffic. Further enhancements to NADIN, such as 
increasing link capacities, providing dedicated virtual channels and/or providing 
special priorities for NAS-NAS messages, could reduce the network delays. 

2. Back-Up Service . The current NAS-NAS Network provides redundant, full- 
duplex lines for each network link. Thus, if one line is lost, the other can provide 
the complete, undegraded service. Initial NADIN and NADIN IA provide a dial 
back-up system for use in the event of primary line outages. This back-up 
system, which uses the nationwide, commercial circuit-switched network, does 
not provide the same quality of service as that of the NAS-NAS Network. 
Specifically: 

• it requires longer to reestablish connections after a line outage; and 

• it does not provide link qualities equivalent to those of the primary 
leased lines. 

1.4 STUDY APPROACH 


In order to determine the most cost/beneficial approach for the support of NAS-NAS 
communications, a four step analysis methodology has been employed. These steps are 
identified below, including references to the more detailed presentations later in this report. 

Step 1 . Identification of the environment and requirements associated with 
NAS-NAS communications (Section 2). 

Step 2 . Identification of alternative approaches for enhancing NADIN to meet the 
NAS-NAS requirements (Section 3, with additional details provided in 
Appendices A, B and C). 

Step 3 . Analysis of the individual alternatives (Section 4). 

Step 4 . Comparative evaluation of the various alternatives (Section 5). 
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SECTION 2 


COMMUNICATIONS ENVIRONMENT AND REQUIREMENTS 


2.1 INTRODUCTION 


As a first step in the analysis of approaches to support NAS-NAS communications, a 
requirements profile was developed. That profile has three major components: 

Communications Environment: (Section 2.2 ) - This section presents an overview of 
current FAA flight data communications, emphasizing the NAS-NAS Network. A brief 
discussion of NADIN and its relationship to such communications is also included. 

Strategic Requirements: (Section 2.3 ) - This section identifies the qualitative 

requirements that would apply to any communications utility being considered to serve 
the NAS-NAS functions. These requirements, which provide scope and direction to 
subsequent analyses, include objectives, policy and cost analysis procedures. 

Tactical Requirements: (Section 2.4 ) - This section identifies the quantitative 

requirements that would apply to any communications utility being considered to serve 
the NAS-NAS functions. These requirements, which govern the development of design 
details, include connectivity, capacity and performance. 

2.2 COMMUNICATIONS ENVIRONMENT 

In order to control enroute IFR air traffic, FAA operates 20 ARTCCs within the 
counterminious U.S. (CONUS). These centers and the area each controls are indicated in 
Figure 2-1. Because of their key role in air traffic control, these centers are major nodes in 
a variety of FAA communications networks and, in particular, have been selected as 
communications concentrator locations for NADIN. 
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2.2.1 General Flight Data Communications 

Effective air traffic control requires that timely information about planned and active 
IFR flights be made available to FAA controllers at the centers and at facilities in terminal 
areas which the flights use or overfly. Flight data are provided to the centers from a 
number of sources. These include: 

• flight service stations, airline offices, military base operations (BASOPS) and 
non-U.S. centers and stations, which provide original flight plans and flight plan 
amendments, 

• terminal areas, which provide flight plans and progress data, 

• radars, which provide flight position and identification data, and 

• neighboring ARTCCs, which provide flight plans and track data for flights 
crossing center boundaries. 

The high volume of air traffic and the resulting high volume of flight data made it 
mandatory that the associated data processing functions be automated. For this purpose, 
FAA has installed a computer complex at each ARTCC. These complexes, using NAS 9020 
computers (also referred to as the NAS En Route Stage A computers), process all flight 
related data received by the center and, at the appropriate time, pass pertinent data on to: 

• enroute controllers at the ARTCCs, 

• terminal area controllers and computers, 

• the central flow control computer, and 

• neighboring center computers. 
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2.2.2 Current Flight Data Networks 


The NAS 9020 computers receive and disseminate flight data through a variety of 
communications networks and circuits (Reference 1). Many of these circuits are 
intra-center (i.e., they provide enroute controllers and other center personnel access to 
flight data) or provide direct computer input from remote radars. Of greater interest for 
this study are the networks and circuits connecting the NAS 9020s with facilities outside of 
the center. These are indicated in Figure 2-2 and are described briefly below. 

The Area B/Supplemental B Networks connect the NAS 9020s with teletype terminals 
at flight service stations and non-U.S. centers and stations. These networks primarily 
provide for flight plan data entry to the computers. Computer outputs over these networks 
primarily include displays of previously entered data and messages related to input 
acceptance or rejection. 

The Utility B Circuits connect the NAS 9020 computers to teletype terminals at 
airline offices and military BASOPS within the centers' control areas. These circuits serve a 
function similar to the Area B/Supplemental B Networks. 

The Center B Network is primarily a teletype-to-teletype network interconnecting the 
ARTCCs and special FAA administrative and support facilities. The NAS 9020s are linked 
to this network to permit limited message transmission to the Central Flow Control Facility 
in Washington, D.C. 

The FDEP Circuits interconnect the NAS 9020 computers with keyboards and flight 
strip printers at towers and approach control facilities in terminal areas. These circuits 
primariy provide for the exchange of flight plans and progress data between the terminal 
area controllers and the NAS 9020. 

The Computer B (NAS-ARTS) Network interconnects <»»ch NAS 9020 computer 
complex with Automated Radar Terminal System (ARTS) computers located in the busier 
terminal areas. This network provides for the automatic exhange of flight plan and track 
data and facilitates the handoff of flights that cross terminal area boundaries. 

The Computer B (NAS-NAS) Network interconnects the NAS 9020 computers at 
(generally) adjacent ARTCCs. This network provides for the automatic exchange of flight 
plan and track data for flights that cross center boundaries and facilitates the handoff of 
such flights. Portions of this network are also used as part of the Automated Flow Control 
(AFC) Store-and-Forward Network, discussed below. 

The AFC Store-and-Forward Network connects the NAS 9020 computers with the 
Jacksonville Computer Complex (JCC). This network provides for the transfer of flight 
plans and progress data (on selected flights) from the ARTCCs to the JCC. It provides 



















direct connections between the JCC and the NAS 9020 computers at five ARTCCs, called 
Forwarding Centers. Messages from other ARTCCs are routed through the Forwarding 
Centers on a store-and-forward basis using specific NAS-NAS Network links. 


2.2.3 The NAS-NAS Network 

The current NAS-NAS Network is composed of 90 independent point-to-point 
communications links. The nodes of the network are the NAS 9020 computers at the 20 
CONUS ARTCCs. The interconnectivity between these nodes is shown in Figure 2-3. 

Each connection shown in Figure 2-3 actually represents two distinct communications 
links. This is illustrated in Figure 2-4. Between every pair of interconnected 9020s there 
are two 2400 bit per second (b/s) full duplex lines, each primarily responsible for carrying 
message traffic in one direction. Should one of the two lines fail, the full duplex capability 
of the other is used to handle all the traffic. Should both lines fail, messages are 
automatically routed to a printer at the sending center. Supervisory personnel are then 
responsible for transmitting the messages to the destination center by teletype or voice 
communications. 

The lines are interfaced with the 9020s through modems, which are directly connected 
to Interfacility Input (INTI) and Interfacility Output (INTO) Adaptors in the Peripheral 
Adaptor Modules (PAM) of the 9020s. Although not shown in Figure 2-4, each modem is 
connected to two INTI and two INTO adaptors on separate PAMs, in order to insure high 
availability. (Detailed discussion of the interface is contained in References 2 and 3). Data 
transferred through the INTI/INTO adaptors must use 9 bit (8 data bits plus 1 parity bit) 
characters. The bits are transmitted serially. 

The NAS-NAS Network is used to transmit 13 types of messages (ignoring AFC store- 
and-forward messages) between the 9020s. These are discussed briefly below, in terms of 
four message categories. (Detailed discussion of each message type is provided in 
References 4 and 5.) 

2.2.3.1 Flight-Data Messages 

Prior to the time that an IFR flight is expected to cross the boundary between two 
ARTCCs, the currently controlling center (sending center) must transmit the associated 
flight plan data to the center that is to have control following the boundary crossing 
(receiving center). Such data is transmitted through four types of messages: 
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Flight Plans (FP) - the current flight plan as stored by the sending center, 


Amendment Messages (AM) - updates to a flight plan previously transmitted, 

Remove Strip Messages (RS) - instructions to the receiving center to delete all 
previously transmitted flight plan data for specific flights, and 

Hold Messages (HM) - notifications to the receiving center that flights for which data 
were previously transmitted are in an indefinite hold status. 

2.2.3.2 Track-Data Messages 

As boundary crossing becomes imminent, flights will be handed off through a series of 
track-data messages. Three types of messages are used: 

Initiate Transfer Messages (TI) - notification from the sending to receiving center 
that the hand-off process is beginning, 

Track Update Messages (TU) - updates of flight velocity and coordinates for flights in 
hand-off status, transmitted from the sending to receiving center, and 

Accept Transfer Messages (TA) - notification to the sending center that the receiving 
center has accepted a handoff, or notification to the receiving center that the sending 
center is taking the flight out of hand-off status. 

2.2.3.3 Response Messages 

Whenever a NAS 9020 receives a flight-data or track-data message, other than a TU, 
it automatically responds with one of three messages: 

Accept Message (DA) - indicator that a valid message with no errors was received, 

Request Retransmission Message (DX) - instruction to retransmit a message that was 
received with transmission errors, and 


Reject Message (DR) - notification that an unacceptable message was received. 








2.2.3.4 Miscellaneous Messages 


Other messages are also transmitted infrequently between the 9020 computers. These 
include: 

• General Information Messages (GI), 

• Test Messages (TR), and 

• Center Operational Messages. 

2.2.4 NADIN 


NADIN (Reference 6) is being developed as a common data communications network to 
integrate many of the currently separate FAA communications networks and to facilitate 
the addition of new FAA communications services. Figure 2-5 illustrates the basic elements 
of the initial NADIN implementation. 

NADIN concentrators will be located at each of the 20 CONUS ARTCCs plus 
Anchorage, Honolulu and San Juan. Each concentrator is directly connected to one of two 
NADIN switches (backup connection to the second switch is also provided). The switches 
and concentrators are further connected to a variety of computers and data terminals which 
constitute the origins and destinations of the messages handled. In particular, each NADIN 
concentrator will be directly connected to the collocated 9020 complex. 

Initial implementation of NADIN (expected by early 1983) will direct all messages to a 
NADIN switch. The switch will administratively process the messages and route them to the 
desired destinations. Among the services to be included as part of the initial implementa¬ 
tion are Area B/Supplemental B, Utility B and Center B. The FDEP service, as upgraded 
under the FDIO program, and the AFC Store-and-Forward service are also expected to be 
incorporated at the time of or shortly after initial implementation. Thus, the external 
NAS 9020 communications by late 1983 should appear as shown in Figure 2-6. 

A variety of enhancements are being considered for NADIN. Thus, to more efficiently 
accommodate the FDEP/FDIO service, local switching at the NADIN concentrators 
(Reference 7) is to be provided as part of the first NADIN enhancement (NADIN IA). This 
feature will have the concentrator (rather than the NADIN switch) route pertinent classes 
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OODO 



SWITHEJ - 2; E-ATLANTA, W-SALT LAKE CITY 

CONCENTRATORS - 23; ONE AT EACH ARTCC AND ANCHORAGE, HONOLULU, AND 
SAN JUAN 

TERMINALS - UP TO ABOUT 50 PER CONCENTRATOR THROUGHOUT EACH ARTCC AREA, 
PLUS SOME AT SWITCHES. SOME ON DEDICATED CIRCUITS, MOST ON MULTIPOINT 

EXTERNAL SYSTEMS AND NETWORKS, E.G., INTERNATIONAL AFTN, WMSC 


FIGURE 2-5: NADIN I SCHEMATIC 
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FIGURE 2-6: EXTERNAL COMPUTER COMMUNICATIONS (NAPIN 1983 ) 







of messages whose origins and destinations are both within the area controlled by the 
associated ARTCC (this is the case for FDEP messages). Another possible enhancement 
involves direct connections between selected concentrators, thereby providing alternate 
routing capabilities. This feature would appear to offer benefits if the NAS-NAS service 
were incorporated ii to NADIN. 

2.3 STRATEGIC REQUIREMENTS 

A communications utility must meet the folowing strategic requirements in order to 
be considered an acceptable alternative for handling the NAS-NAS traffic. 

2.3.1 Objectives 

The NAS-NAS utility must satisfactorily perform the current functions of the 
NAS-NAS Network (other than those associated with the Network's interim role as part of 
the AFC Store-and-Forward Network). Since the current NAS-NAS Network is satisfactory 
and since the NAS 9020 computer system is due to be replaced around 1990, a utility to 
replace the current network must perform the NAS-NAS functions at a total cost no greater 
than the current network, and with minimal changes to the computer system. 

The requirement for minimal change leads to many of the tactical requirements 
presented later. At the strategic level, this requirement implies: 

• the NAS-NAS utility must require no changes to the NAS 9020 software, other 
than minor modifications to accommodate a new interface, and 

• the utility must be transparent to enroute controllers, thus avoiding the need for 
special training (i.e., it must introduce no new or altered controller activities, 
nor modify the displays received by the controllers). 

2.3.2 Policy 

The utility must be consistent with FAA Order 1830.2 (Reference 8). That order 
identifies sets of standards related to communications codes, signalling rates, transmission 
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modes, bit sequencing, character structure, link control procedures, message transfer and 
electrical and physical interfaces to be implemented as part of new or upgraded FAA data 
communications systems. 

2.3.3 Cost Estimation 


As indicated earlier, the NAS-NAS utility must cost no more than the current 
NAS-NAS Network. Cost comparisons must reflect the following, in addition to standard 
considerations. 

• Comparisons must be based on life-cycle costs; i.e., they must appropriately 
combine one-time «nd recurring costs. 

• Comparisons must be based on differences in cost to the total FAA program. 
Thus, since NADIN concentrators and switches will be purchased regardless of 
NAS-NAS utility selected, their costs need not be considered. Similarly, when a 
utility based on NADIN is considered, only the incremental costs of enhancing 
NADIN must be included. For such considerations it will be assumed that 
NADIN IA (Reference 9) is to be funded and implemented by 1983, regardless of 
any decision concerning the NAS-NAS utility. 

2.4 TACTICAL REQUIREMENTS 

A communications utility must meet the following tactical requirements in order to be 
considered an acceptable alternative for handling the NAS-NAS traffic. 

2.4.1 System Configuration 

The nodes of the NAS-NAS communications service are the NAS 9020 computer 
complexes at the 20 CONUS ARTCCs. In general, each center must have connectivity with 
every other center sharing a common boundary. In addition, since some flights using 
overwater routes bypass intervening ARTCC air space, connectivity is required between: 
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^^5555 


• New York and Jacksonville 

• New York and Miami 

• Miami and Houston 

No connectivity is required between Houston and Albuquerque, since no air lanes cross the 
short common boundary between those centers. 

The required connectivity is indicated by the current two-way Computer B (NAS-NAS) 
Network links, shown earlier in Figure 2-3. The direct connectivity provided by the current 
network is, however, not necessarily required. 

2.4.2 Message Traffic 

The NAS-NAS message traffic that must be handled by the utility is the current 
NAS-NAS traffic (ignoring AFC store-and-forward traffic) and its projections to CY 1988 
(the year the NAS 9020 replacement is to begin). The best "current" message traffic data 
available are those developed as part of the 1978 study of the impact of AFC store-and- 
forward traffic on the NAS-NAS Network (Reference 10). Those data were obtained from 
detailed analysis of System Analysis Recording (SAR) tapes provided from all 20 ARTCCs. 
The ARTCCs were requested by letter (Reference 11), dated December 23, 1975, to provide 
tapes "of at least 20 minutes duration selected from each ARTCC's peak traffic hour for any 
convenient week since November 15, 1975." 

The 1976 study identified eight message types that constituted over 99 percent of the 
NAS-NAS peak-period message traffic. These are: 


TI - 

initiate transfer 

TU - 

track update 

TA - 

accept transfer 

FP - 

flight plan 

AM - 

amendment messages 

RS - 

remove strip 

DA - 

data accept 

DR - 

data reject 
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The only change anticipated in the message traffic for the 1983-88 time frame is the traffic 
volume. The message types, their relative frequencies and their lengths are expected to 
remain unchanged. 

2.4.2.1 Message Lengths 

Analysis of the SAR tapes for the 1976 study produced the NAS-NAS message length 
data shown in Table 2-1 These data require no adjustment for use in this study. 

2.4.2.2 Message Traffic Volumes 

Analysis of the SAR tapes for the 1976 study produced the NAS-NAS message traffic 
volumes (in messages per hour) for individual links shown in Table 2-2. As indicated earlier, 
the specific nodes and the interconnectivity requirements are not expected to change for 
the 1983-88 time frame. Only the traffic volumes shown are expected to change. These 
should grow in proportion to the growth in IFR air traffic that crosses center boundaries. 

An estimate of the growth rate has been obtained from FAA forecasts of IFR aircraft 
handled by the individual centers (Reference 12). Selected data from that source are shown 
in Table 2-3. Implied growth factors, relative to the 1976 data are shown in Table 2-4. 

In order to obtain a conservative estimate of message traffic growth, the maximum 
growth factors (1.8 for 1983, 2.2 for 1988) have been used. The results of applying these 
factors to the 1976 traffic volumes are shown in Table 2-5 (for 1983) and 2-6 (for 1988). 

2.4.3 Transmission Delays 

AH flight-data and track-data messages must be transmitted and (except for TU 
messages) responded to without undue delay. Internal NAS 9020 delays in responding to such 
messages must average no more than 2 secoinds, and must be less than 4 seconds, 90 percent 
of the time (Reference 13). Delays due to message queueing and actual (one-way trans¬ 
mission of the data and response messages must average no more than 1 second, and must be 
less than 2 seconds 90 percent of the time. These requirements are summarized in 
Table 2-7. 
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Message 

Type 

Relative 

Frequency 

Message Lengths (characters) 

Coeff. 
of Var. 

Average 

Maximum 

Minimum 

TI 

.082 

44.2 

49 

38 

.10 

TU 

.367 

33.8 

88 

28 

.25 

TA 

.077 

25.4 

30 

22 

.08 

FP 

.092 

79.1 

372 

52 

.34 

AM 

.062 

55.8 

254 

29 

.45 

RS 

.002 

26.5 

30 

25 

.09 

DA 

.310 

28.1 

36 

23 

.24 

DR 

.007 

23.9 

32 

19 

.56 

ALL 

1.000 

37.7 

372 

19 

.54 


Notes: 

Coefficient of Variation = Sample Standard Deviation/Average Length. 
Message Length includes all current overhead characters. 


Source: FAA-RD-76, Automated Flow Control Interim Communications, 
August, 1976. 


TABLE 2-1 : NAS-NAS MESSAGE LENGTH DISTRIBUTIONS 
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IFR AIRCRAFT HANDLED (thousands) 


Center 1976 (Act.) 1983 (Est.) 1988 (Est.) 


Albuquerque 

845 

1,183 

1,384 

Atlanta 

1,400 

1,989 

2,365 

Boston 

912 

00 

©* 

c* 

rH 

1,456 

Chicago 

1,851 

2,643 

3,276 

Cleveland 

1,652 

2,524 

3,155 

Denver 

722 

1,149 

1,380 

Fort Worth 

1,323 

1,984 

2,459 

Houston 

1,172 

1,842 

2,272 

Indianapolis 

1,336 

2,006 

2,484 

Jacksonville 

1,105 

1,610 

1,836 

Kansas City 

1,080 

1,656 

1,966 

Los Angeles 

1,091 

1,624 

1,868 

Memphis 

1,151 

1,732 

2,115 

Miami 

1,039 

1,686 

1,998 

Minneapolis 

1,003 

1,600 

1,970 

New York 

1,499 

2,180 

2,578 

Oakland 

952 

1,384 

1,645 

Salt Lake City 

462 

783 

923 

Seattle 

695 

1,234 

1,540 

Washington 

1,396 

1,995 

2,434 

TOTAL 

22,686 

34,032 

41,104 


Source: FA A- AVP-79-1, IFR Aircraft Handled, forecast by Air Route Traffic 
Control Center, Fiscal Years 1979-1990, April, 1979. 


TABLE 2-3: ANNUAL IFR AIRCRAFT HANDLED BY CENTER 
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GROWTH FACTOR* 



1983 

1988 

20-Center Average 

1.5 

1.8 

Maximum 

(Seattle) 

1.8 

2.2 

Minimum 

(Boston) 

1.3 

1.6 

Busiest Center 
(Chicago) 

1.4 

1.8 

Least Busy Center 
(Salt Lake City) 

1.7 

2.0 


*Ratio of IFR Aircraft Handled for indicated 
year to IFR Aircraft Handled in 1976. 


TABLE 2-4: RELATIVE GROWTH OF IFR AIR TRAFFIC 
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ACTIVITY 

NAS-NAS Message Transmission 
(FP, AM, RS, HM, TI, TO, TA) 

NAS 9020 Response Processing 

NAS-NAS Response Transmission 
(DA, DX, DR) 


TABLE 2-7: ACCEPTABLE DELAYS FOR NAS-NAS TRAFFIC 


DELAY TIMES (seconds) 
MEAN 90 PERCENTILE 

1 2 

2 4 

1 2 
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2.4.4 Availability/Reliability 

The NAS-NAS service must be operational seven days a week. Between any two 
centers, the utility must be operational during the hours when both centers are to be 
operational. This will be a maximum of 24 hours a day. 

Utility outages cannot be completely avoided. The importance of the NAS-NAS 
message traffic thus requires a back-up service. Currently, this is provided by redundancy 
and through off-line printing of messages for transmission over intercenter teletype or voice 
circuits. The latter type operations cannot be tolerated too frequently or for too long a 
period. The NAS-NAS utility must thus meet the following reliability requirements: 

• Mean Time Between Failures (MTBF) - greater than 1000 operational hours (less 
frequently than once per month). 

• Mean Time to Repair, Replace or Bypass (MTTR) - 15 minutes or less. 


2-24 





SECTION 3 


IDENTIFICATION OF ALTERNATIVES 


3.1 INTRODUCTION 


Five alternatives for supporting NAS-NAS communications have been analyzed. The 
first, Alternative 1, is the current NAS-NAS Network. Three involve the enhancement of 
NADIN to completely take over the NAS-NAS service. One involves the combined use of 
the current NAS-NAS Network and NADIN. 

The four alternatives involving NADIN have been specifically tailored to overcome one 
or more of the limitations identified earlier. Thus: 

• Alternative 2, Enhanced NADIN IA, includes increased capacities on selected 
links to assure acceptable NAS-NAS message delays. 

• Alternative 3, Enhanced NADIN Architecture, provides for increased 
connectivity among NADIN nodes and packet switching among those nodes, to 
reduce network delays and minimize the need for a separate back-up system. 

• Alternative 4, NAS-NAS/NADIN IA, eliminates the redundant NAS-NAS 
Network lines, using NADIN IA as a back-up in the event of line outage, thus 
reducing the NAS-NAS Network cost and facilitating full transition to NADIN at 
a later time. 

• Alternative 5, Redundant NADIN IA, is essentially Alternative 2, with one extra 
(9,600 b/s) line on each backbone link, to increase availability and thus decrease 
reliance on a dial back-up system. 

One of the major considerations in defining the NADIN alternatives was to assure that 
NAS-NAS message delay constraints would be met. As a general rule, such assurance can be 
achieved by providing special handling for NAS-NAS messages, e.g.: 
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• Under Alternative 2, NAS-NAS messages could be assigned higher priorities than 
other ATC messages, thus minimizing the queueing delays at the network nodes; 
and 

• under Alternative 3, permanent virtual circuits could be established for 
NAS-NAS messages, thus reducing node processing delays. 

Although such approaches are valid and should be investigated further, they were not 
used in the detailed analyses of this study. Rather, acceptable delays were assured by 
increasing the capacity of selected network links. This approach was felt to be most 
appropriate at this time for the following reasons: 

1. It is not clear that any class of ATC messages should be given special handling 
relative to other classes of ATC messages. 

2. Providing special handling for NAS-NAS messages can be expected to increase 
the network delays for other NADIN traffic. A broader study would be required 
to investigate network adjustments needed to meet the delay constraints for the 
other traffic, if NAS-NAS messages were given special treatment. 

3. The approach used, i.e., increasing link capacities, represents a conservative 
approach, both in terms of cost and technology. 

4. Even with the approach used, it was possible to demonstrate the feasibility and 
cost-effectiveness of NADIN support for NAS-NAS communications. 

Each of the five alternatives is defined and described in the subsections below. Each 
is analyzed separately in Section 4. 

3.2 ALTERNATIVE 1, THE CURRENT NAS-NAS NETWORK 

The first alternative considered for the support of NAS-NAS requirements is the 
continued use of the current, independent NAS-NAS Network. That network has been 
described in Section 2. Of particular interest for this analysis are the following features of 
the network (see Figure 3-1): 
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FIGURE 3-1: TYPICAL NAS-NAS MESSAGE PATHS, ALTERNATIVE 1 












• The network provides a direct, redundant connection between every pair of 
NAS-9020 computer complexes that exchange NAS-NAS messages. 

• Each link consists of two full-duplex, voice-grade channels, each operating at 
2,400 bits per second (b/s). 

• Normally, each of the two channels supports transmissions in one direction only; 
in the event of a channel outage, the full-duplex capability of the remaining 
channel is used to support two-way transmissions. 

This network has proven to be highly effective. However, because of the direct, 
dedicated, redundant connections, it is relatively expensive. 

3.3 ALTERNATIVE 2, ENHANCED NADIN IA 

The second alternative considered for NAS-NAS communications support is the use of 
NADIN, essentially as configured under the Level IA implementation. This network has also 
been described in Section 2. Of particular interest in this analysis are the following features 
(see Figure 3-2): 

• A NADIN concentrator will be located at each of the 20 CONUS ARTCCs, 
collocated with the NAS 9020 computer complexes. 

• Using this alternative, each NAS-NAS message would always be routed through 
one or both NADIN switches, located at the Atlanta and Salt Lake City ARTCCs. 

• Using this alternative, NAS-NAS message traffic would have to contend with 
other high-priority ATC traffic for use of the network backbone links. 

• Under the Level IA implementation, NADIN backbone links will consist of one or 
two full-duplex, voice-grade channels, each operating at 9,600 b/s; the 
multiplicity (and, hence, capacity) of these links can be increased to meet added 
requirements. 
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FIGURE 3-2: TYPICAL NAS-NAS MESSAGE PATHS, ALTERNATIVE 2 






Alternative 2 would eliminate the need, and therefore the cost, for operating and 
maintaining the current NAS-NAS Network. Since NAD1N 1A has been designed for a 
variety of users and will include interfaces with the NAS 9020 computers, the cost to 
implement Alternative 2 should be relatively small. Specifically, the only major costs 
involved would be costs for minor modifications to the 9020 software (to adapt NAS-NAS 
messages to the NADIN interface) and costs for increasing link capacities to insure that the 
NAS-NAS delay constraint is met. 

An analysis has been performed (see Appendix A) of the network delays that would 
result if the NAS-NAS traffic were directly added to NADIN IA. That analysis indicated 
that the capacities would have to be increased on fifteen of the NADIN LA backbone links in 
order that the NAS-NAS delay constraint be met. Table 3-1 identifies the specific links 
involved. 

3.4 ALTERNATIVE 3, ENHANCED NADIN ARCHITECTURE 

The third alternative involves a significant modification to NADIN. All NADIN 
concentrator nodes would be converted into combined concentrator/packet-switcti nodes. 
Most of the message processing functions would remain with the two NADIN IA message 
switches. 

The backbone nodes (packet switches) for this alternative would be interconnected so 
as to create a distributed network (see Figure 3-3). The specific links and link capacities 
would be selected so that: 

• network delay constraints were not exceeded, 

• each pair of switches would be (directly or indirectly) connected by at least two 
non-overlapping routes, and 

• network costs would be minimized. 

Under Alternative 3 it would still be necessary to route some messages (but not 
NAS-NAS messages) through the message switches at Atlanta and Salt Lake City. These 
would primarily include those messages that require recording for historical purposes, those 
associated with external systems and those that are generated with less sophisticated 
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LINK 

NODES 

NUMBER OF 9,600 B/S 

CHANNELS ON LINK 

NADIN IA 

ENHANCED 
NADIN IA 

Atlanta (C) > 


1 

2 

Boston 


1 

1 

Chicago 


1 

2 

Cleveland 


1 

2 

Indianapolis 


1 

2 

Jacksonvilie 

> Atlanta (S) 

1 

2 

Memphis 


1 

2 

Mi ami 


1 

2 

Minneapolis 


1 

2 

New York 


1 

2 

Washington 

1 

2 

Atlanta (S) 

Salt Lake City (S) 

2 

2 

*\ 




Albuquerque 


1 

1 

Denver 


1 

2 

Fort Worth 


1 

2 

Houston 

s. Salt Lake City (S) 

1 

2 

Kansas City 


1 

2 

Los Angeles 


1 

1 

Oakland 


1 

1 

Salt Lake City (C) 


1 

2 

Seattle J 


1 

1 

TOTAL 

22 

37 


NOTES: 


1. The Atlanta and Salt Lake City nodes are indicated as either 
being concentrators (C) or switches (S). 

2. Backbone links to off-shore centers are not included. 


TABLE 3-1: LINK CAPACITY MODIFICATIONS UNDER ALTERNATIVE 2 
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FIGURE 3-3: TYPICAL NAS-NAS MESSAGE PATHS, ALTERNATIVE 3 






terminal equipment. There will never be a requirement to route a message through both 
switches. 

A more complete discussion of this concept and its impact on the NADIN architecture 
are presented in Appendix B. An analysis was performed to determine a typical topology for 
such a network; i.e., linkages and link capacities. The analysis is presented in Appendix C; 
the optimal topology determined is indicated in Figure 3-4. 

3.5 ALTERNATIVE 4, NAS-NAS/NADIN IA 

The fourth alternative retains the basic NAS-NAS Network, but eliminates the 
redundant line on each link. This cuts the cost almost in half, but also reduces link 
reliability. 

To provide back-up service in the event of a NAS-NAS line outage, this alternative 
includes an interface with NADIN IA. Since NADIN would serve the NAS -NAS traffic only 
sporadically, there need be no enhancement of NADIN IA specifically to accommodate such 
traffic. As a result, the primary NAS-NAS service under this alternative would be 
essentially the equivalent to that under the current NAS-NAS Network. The back-up 
service, although ar. improvement over the manual back-up system for the current network, 
would be expected to be used more often, and would not provide as good service as the 
current redundant lines. 

3.6 ALTERNATIVE 5, REDUNDANT NADIN IA 

A major difference between Alternative 2 and the other three alternatives defined 
above is the quality of the back-up service, should a primary line be lost. Alternative 1 
includes redundant lines for such contingencies; Alternative 3 provides alternate routes; 
Alternative 4 uses NADIN I A. Should a primary line under Alternative 2 be lost, back-up 
service would be provided by a dial-up, circuit-switched system. 

Alternative 5 attempts to overcome this limitation by including all the enhancements 
to NADIN IA as are included under Alternative 2 and by further including one additional 
9600 b/s line on each backbone link. Thus the loss of any one line will result in no service 
degradation. 





FIGURE 3-4: OPTIMAL ALTERNATIVE 3 CONFIGURATION 









SECTION 4 


ANALYSIS OF ALTERNATIVES 


4.1 INTRODUCTION 


As described in Section 3, the five alternatives considered for supporting NAS-NAS 
communications can meet all NAS-NAS requirements. Selection of a preferred alternative 
must thus be based on the comparison of additional features each provides and cost. Review 
of the five alternatives reveals four major areas to be considered in such a comparison. 
These are cost, throughput performance, back-up service and long-range potential. Only the 
first, cost, provides for a strictly quantitative comparison. 

4.1.1 Cost 


The methodology and parameters used to determine comparative costs for the five 
alternatives are presented in Appendix D. The major considerations include: 

• A single comparative cost is determined for each alternative; this is the ten-year 
life cycle cost. 

• The life cycle cost is calculated in terms of present value in 1983, assuming a 
ten percent net annual discount rate. 

• The Multi-Schedule Private Line (MPL) tariffs are assumed to apply for the 
communications links under all five alternatives. 

• It is assumed that funds required to implement NADIN IA without further 
enhancements and to operate it for ten years will be committed regardless of the 
NAS-NAS alternative selected. Thus, only incremental enhancements costs are 
included. 
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4.1.2 Throughput Performance 

One facet of throughput performance, i.e., the end-to-end delays under projected 1988 
throughput requirements, is actually reflected in the costs determined for each alternative. 
Thus, links are added and/or link capacities increased, as needed, to meet the delay 
constraints. The cost for such adjustments are included in the life cycle cost calculations. 

This category of comparison thus reflects primarily the ability of the alternatives to 
handle temporary surges in throughput requirements. Generally, systems with more excess 
capacity or with means of avoiding further use of nearly congested links would rate better 
under this area of comparison. 

4.1.3 Back-Up Service 

Both the NAS-NAS Network and NADIN have been designed to provide high 
availability/reliability. There are, however, major differences in the quality of service 
available among the five alternatives should a primary line be lost. Further, some, through 
redundancy or alternate routing, include a back-up capability within the primary service. 
This category of comparison thus reflects the combination of the quality of back-up service 
and the likelihood that the back-up service would be required. 

4.1.4 Long-Range Potential 

Long-range potential is used here to refer to the benefits that might be realized from 
implementing a specific NAS-NAS alternative relative to broader, long-range ATC 
objectives and requirements. The ability to handle increasing traffic levels is actually 
reflected under throughput performance, and therefore is specifically excluded from this 
area of comparison. 

The major considerations under long-range potential are thus the ability of each 
alternative to support or facilitate major long-range ATC programs. These primarily 
include: 

• the ATC Computer Replacement Program (CRP), 

• the Advanced EnRoute Automation Program (AERA), and 


4-2 



• Center Back-Up, which is associated with, but basically separate from, both CRP 
and AERA. 


4.2 ALTERNATIVE 1, THE NAS-NAS NETWORK 

Since the NAS-NAS Network exists and is operationally satisfactory, analysis of 
Alternative 1 has been directed primarily to the establishment of a basis for comparisons 
among the alternatives. Of specific interest are the expected delays under projected 1988 
message traffic levels and the cost of retaining the NAS-NAS Network. 

4.2.1 Alternative 1 Throughput Performance 

Under Alternative 1 the transmission of a NAS-NAS message would involve use of only 
a single network link. Further, only NAS-NAS traffic and associated link control traffic 
would be transmitted on that link. As a result the greatest network delays would be 
encountered on the channel carrying the greatest volume of NAS-NAS traffic. 

The data in Section 2 identifies the Miami-to-Jaeksonville channel as the busiest in the 
NAS-NAS Network. It has been projected that in 1988 there would be 2,332 NAS-NAS 
messages transmitted over that channel during a peak hour, with each message averaging 
37.7 (9-bit) characters. This projection includes all bits, characters and messages 
transmitted as overhead on the channel. 

This message transmission requirement translates into a gross throughput requirement 
(GT) of: 

GT = 2,332 x 37.7 x 9/3600 

= 220 b/s during the peak hour. 

The average message transmission time (TF) on the 2400 b/s channel would be: 

TF = 37.7 x 9/2400 = .141 seconds 
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The average queueing delay (TQ) prior to transmission of a message would be: 


TQ - TF x U/(l-U) 

where U - the link utilization 

= GT/2400 

= 220/2400 = .092 

Thus: TQ = .141 x .092/.908 = .014 seconds 

The queueing delay and transmission time are the only significant "network" delays 
encountered under Alternative 1. Thus the average network delay (TD) on the busiest 
channel would be: 

TD = TF + TQ 

= .141 + .014 = .16 seconds 

This maximum average delay is well within the one second delay constraint identified 
for the NAS-NAS traffic. This, together with the very low link utilization (.092), represents 
a very high level of throughput performance. 

The above calculations are based on standard communications analysis models. They 
are discussed in more general terms as part of the Alternative 2 analysis in Appendix A. 

4.2.2 Alternative 1 Costs 


Since the NAS-NAS Network exists and since the link capacities are sufficient for the 
projected 1988 traffic, the only costs associated with Alternative 1 are the monthly charges 
by the communications carrier. Under the MPL tariffs these include: 

• a fixed monthly charge per channel ($51.72), 

• an inter-exchange mileage charge (IXC) for each channel, 
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• a station terminal (drop) charge for each drop on a channel ($26.30), and 

• a channel conditioning charge for each drop on a channel ($15.50). 

The 1XC for one channel on each of the 45 NAS-NAS links is shown in Table 4-1. Since 
each link has two channels and each channel requires two drops, the monthly recurring cost 
(RC) would be determined as shown below: 


Fixed Charges 

: 45 x 2 x $51.72 

= $ 4,655 

IXC 

: 2 x $18,746 

= 37,492 

Drop Charges 

: 45 x 2 x 2 x $26.30 

= 4,734 

Conditioning Charges 

: 45 x 2 x 2 x $15.50 

= 2,790 


RC 

= $49,671 


The life-cycle cost used in comparing the alternatives includes all one-time costs and 
the present value (PV) of all recurring costs, applicable over a 10 year system lifetime. 
Since there are no one-time costs for Alternative 1, the life-cycle cost (LC) would be (see 
Appendix D): 

LC = PV = RC x (1-(1+D)" m )/D 
where D = the assumed net discount rate 

= .008 per month (0.1 per year) 

m = system lifetime 

= 120 months 


Thus: LC = $49,671 x 77.0 = $3.82 million 
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link nodes 


DISTANCE 


UC 

.S/CHANNE./MONTri, 


(MIllS! 


Albuquerque 


At 1ant 3 


3oston 


Chicago 


C1eveland 


Denver 


Fort Worth 


Houston 


CleveI and 
New York 


Indianapolis 
Minneapolis 
New York 
Washington 


Kansas City 
Los Angeles 
Minneapolis 
Salt Lake City 


Houston 
Kansas City 
Memphis 


Jacksonvi1le 

Memphis 

Miami 


561.7 

158.7 


232.3 
598.6 

476.3 
288.0 


555.8 

846.8 

684.9 
359.4 


222.5 

437.2 

435.8 


304.1 

473.1 

972.2 


Denver 

Fort Worth 

Kansas City 

Los Angeles 

361.6 

568.9 

704.0 

671.1 

S313.20 

456.20 

549.50 

526.70 

Houston 

693.4 

542.10 

Indianapolis 

454.2 

377.00 

Jacksonv 1 1 le 

232.3 

223.90 

Memphis 

351.1 

305.90 

Washington 

545.4 

440.00 


451.30 
17 3.20 


Cleveland 

317.5 

282.70 

Ind i anapolis 

177.9 

136.40 

Kansas City 

396. 7 

337.40 

Minneapolis 

314.2 

280.50 


223.90 

476.70 

392.30 

262.40 


447.20 
648.00 

536.20 
311.70 


217.20 

365.40 

364.40 


618.50 
390.10 

734.50 



TABLE 4-1: INTEREXCHANGE MILEAGE CHARGE (IXC ) 
PER CHANNEL, ALTERNATIVE 1 (Page 1 of 2) 
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4.2.3 Alternative 1 Back-Up Service 


The high availability/reliability of the current NAS-NAS Network is provided through 
three design elements: 

• point-to-point connections between each pair of centers that exchange NAS-NAS 
messages, 

• redundant full-duplex lines and interfaces for each interconnection, and 

• a manual back-up system, should both lines be lost. 

The first two elements assure high availability for at least one end-to-end connection 
between two centers. The parallel redundant lines are, however, more susceptible to 
simultaneous outage from external causes (e.g. storms) than, for example, a network 
providing alternative routing. The last design element represents a relatively poor quality 
back-up service, on those rare occasions when it is needed. 

4.2.4 Alternative 1 Long-Range Potential 

The current NAS-NAS Network offers little long-range potential, as considered for 
this study. The multiple interfaces that this network requires at each center tend to make 
the computer replacement process (e.g., switch-over and testing) more difficult. Further, 
since this network provides communications from one center to only a limited number of 
other centers, it could not directly support Center Back-Up concepts. 


4.3 ALTERNATIVE 2, ENHANCED NADIN IA 


It has been assumed for this study that the Level IA implementation of NADIN will be 
completed in 1983. The incorporation of the NAS-NAS service into NADIN under 
Alternative 2 would thus primarily require: 

• modifying NAS 9020 software to direct NAS-NAS messages to the appropriate 
output adaptor and to include information required by NADIN (e.g., message 
destination) in the NAS-NAS message, and 
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• making the necessary modifications to insure that the NAS-NAS message delay 
contraint is not exceeded. 

4.3.1 Alternative 2 Throughput Performance 

NADIN specifications (Reference 6) require that average peak-period network (end-to- 
end) delays for random message frames be no greater than two seconds. In order to meet 
that requirement for traffic to be handled under the Level IA implementation, it has been 
further specified (Reference 9) that: 

• each link between a NADIN switch and a NADIN concentrator be a full-duplex, 
voice-grade channel, operating at 9,600 b/s, and 

• the link between the two NADIN switches consist of two full-duplex, voice-grade 
channels, each operating at 9,600 b/s. 

The delay constraint for NAS-NAS message traffic is more demanding; i.e., the 
average peak-period network delay must be no greater than one second. The impact of 
implementing Alternative 2, on the delays for both NAS-NAS traffic and NADIN IA traffic, 
has been analyzed. That analysis (see Appendix A) determined: 

1. The overall throughput performance would still meet the NADIN requirements. 

2. By 1988, sixty-three percent of the NAS-NAS origin/destination pairs would 
experience peak-period message delays averaging more than one second, if 
NADIN IA were left essentially unchanged. 

3. The major contributing factor to the excessive delays are the queueing delays on 
the busier switch-to-concentrator legs of the message paths. 

Several approaches are possible for reducing such delays. As suggested earlier, this 
study considered only the increasing of the number and/or capacity of the backbone links. 
The required modifications were shown in Table 3-1. Although these modifications assure 
that the NAS-NAS requirements are met, the throughput performance is relatively low, 
especially on those links retaining only a single 9,600 b/s line. 
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4.3.2 Alternative 2 Costs 


Alternative 2 involves both one-time and recurring costs. The one-time cost items 
include installation charges and modem purchases associated with the added channels and 
the cost of modifying the 9020 software that controls the preparation and output of 
NAS-NAS messages. Installation costs associated with the added channels would apply only 
to 13 of the 15 added channels. This results from the fact that two of the added channels 
are between the switch and concentrator at Atlanta and at Salt Lake City. Those links are 
essentially internal to the respective ARTCCs and should require no significant commercial 
service. It is assumed, however, that modems would be purchased for those channels. 

From Appendix D, the pertinent one-time charges would be: 

• a station installation charge per drop per added commercial channel ($57), 

• a channel conditioning equipment installation charge per drop per added 
commercial channel ($171), 

• modem cost per drop per added channel ($8,500), and 

• software development costs ($150 per instruction). 

It is estimated that approximately 400 instructions would be required to modify the 
software. Thus the one-time costs (OC) would be determined as shown below: 


Modems : 15 x2x$8500 = $ 255,000 

Station Installation : 13 x 2 x $57 = 1,482 

Conditioning Installation : 13 x 2 x $171 = 4,446 

Software : 400 x $150 = 60,000 


OC = $ 320,928 


The recurring costs for Alternative 2 include primarily the monthly charges associated 
with the 13 additional commercial channels. Table 4-2 shows the IXC for these channels. 
(Note, only the column titled Alternative 2 applies here; the column titled NADIN IA is 
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LINK NOOES* 

— 

DISTANCE 

(MILES) 

IXC 

(S/MONTH) 

NADIN IA 

ALTERNATIVE 2 

Altanta (C) 

Atlanta (S) 

0 

S 0 

S 0 

Boston 


951.2 

720.00 

0 

Chicago 


620.0 

491.50 

491.50 

Cleveland 


558.7 

449.10 

449.10 

Indianapolis 


454.2 

377.00 

377.00 

Jacksonvi 1 le 


232.3 

224.00 

224.00 

Memph i s 


351.1 

305.90 

305.90 

Miami 


581.4 

464.90 

464.90 

Minneapolis 


911.5 

692.60 

692.60 

New York 


802.1 

617.10 

617.10 

Washington 


545.4 

440.00 

440.00 

Atlanta (S) 

Salt Lake City (S) 

1,599.5 

2,010.90** 

0 

Albuquerque 


485.8 

398.90 

0 

Denver 


359.4 

311.70 

311.70 

Fort Worth 


983.3 

742.20 

742.20 

Houston 


1,190.1 

833.50 

333.50 

Kansas City 


914.9 

695.00 

695.00 

Los Angeles 


589.7 

470.60 

0 

Oakland 


586.1 

468.10 

0 i 

Salt Lake City (C) 


0 

0 

0 

Seattle 

_J 

684.4 

535.90 

0 

TOTAL IXC 

$11,248.90 

$6,644.50 


* The Atlanta and Salt Lake City nodes are distinguished as being 
either concentrators (C) or switches (S). 


** Value reflects two 9,600 b/s channels. 


TABLE 4-2: INTEREXCHANGE MILEAGE CHARGE (IXC). ALTERNATIVE 2 






included for later reference in considering Alternative 3.) The monthly recurring cost (RC) 
would be determined as shown below: 


Fixed Charge 

: 13 x $51.72 

= 

$ 

672 

IXC 


= 


6,645 

Drop Charge 

: 13 x 2 x $26.30 

= 


684 

Conditioning Charge 

: 13 x 2 x $15.50 

— 


403 


RC 

= 

$ 

8,404 


The present value (PV) of the recurring charges would be: 

PV = $8,404 x 77.0 = $647,108 

The life-cycle cost (LC) would then be: 

LC = OC + PV 

= $320,928 + $647,108 = $.97 million 

4.3.3 Alternative 2 Back-Up Service 

The high availability/reliability of NADIN IA is provided through two design elements: 

• multiprocessor design of concentrators and switches, and 

• a dial back-up system, including dial-up connections to the "other" switch should 
one switch be down. 

Although the dial back-up system would be a major improvement over the NAS-NAS 
Network's manual back-up system, the likelihood that the back-up system would have to be 
used would be greater under Alternative 2. This results from the increased number of links 
(2 or 3) for each connection and the absence of redundant lines under Alternative 2. 
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4.3.4 Alternative 2 Long-Range Potential 


Alternative 2 provides two features of importance to longer-range FAA objectives. 
First, there need be no dedicated NAS 9020 input/output ports for NAS-NAS 
communications. Rather, NAS-NAS traffic will use the same ports provided for general 
NADIN traffic. This would greatly facilitate switch-over and testing for the replacement 
computer. Second, under Alternative 2 a NAS-NAS message from one center can easily be 
routed to any other center, not just neighboring centers. This would greatly facilitate 
1 support for almost any Center Back-Up concept. 

4.4 ALTERNATIVE 3, ENHANCED NADIN ARCHITECTURE 

Alternative 3 requires that the NADIN architecture be modified so that: 

• each of the existing CONUS nodes would contain a concentrator and a packet 

i switch, 

• the Atlanta and Salt Lake City nodes would also include message switches, 
operating essentially like the NADIN IA switches for certain classes of messages, 
and 

r 

j • nodes would be interconnected in a manner that would provide at least two non- 

! overlapping routes between each pair of nodes. 

r: 

[ 4.4.1 Alternative 3 Throughput Performance 

[. Appendix C describes the analysis performed to determine a minimal cost configura- 

' tion wivh the above characteristics that also satisfies the NADIN and NAS-NAS end-to-end 

delay constraints. Figure 3-4 depicted the configuration determined to be optimal. That 
configuration is made up of 31 links, involving thirty-seven 9,600 b/s channels. Nine of 
those channels are also included in the NADIN IA implementation. 
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Although the link capacities under Alternative 3 were selected so as to meet delay 
constraints, just as with Alternative 2, Alternative 3 would have significantly greater 
throughput performance. This is due to the availability of alternate routes between each 
pair of nodes, to help distribute the impact of temporary surges in demand. 

4.4.2 Alternative 3 Costs 


Unlike the other alternatives analyzed, Alternative 3 would involve major modifica¬ 
tions to NADIN. This leads to a number of unique considerations related to system costs. 
The most significant of these are: 

• the treatment of (unmodified) NADIN IA operating costs, which were ignored 
when considering the other alternatives, and 

• NADIN hardware/software modification costs. 


For the other alternatives it has been assumed that the Level IA implementation of 
NADIN would be retained and operated regardless of the alternative selected for handling 
NAS-NAS traffic. Thus, the recurring costs associated with the NADIN IA channels were 
not assigned as costs for those alternatives; only the costs associated with modifications 
(additions) were assigned to pertinent alternatives. 

The modifications associated with Alternative 3 are not simple additions. Rather 
some items associated with NADIN IA are dropped and some new items are added. In order 
to insure comparability between the costs for this and the other alternatives, it has been 
necessary to determine the gross recurring cost for Alternative 3 and to reduce that total by 
the recurring costs of operating NADIN IA without any modifications. 

No detailed analysis has been made of the specific hardware and software require¬ 
ments for Alternative 3. Rather, in order to obtain a reasonable cost estimate, it has been 
assumed that an approach such as shown in Figure 4-1 would be used. 

Under this concept the original NADIN concentrator hardware would be retained as 
the network interface for local connections (the NAS 9020 computer, FSSs, FDIO remote 
site equipment, etc.). The concentrator, rather than directing messages to the Atlanta or 
Salt Lake City switch, would direct all messages (other than those that are locally switched) 
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ALTERNATIVE 3 NADIN SWITCH CONCFPT 
















to a collocated switching module. Modules of this nature are available commercially, 
complete with networking software. 

The one-time costs to implement this concept would thus include the cost to develop 
(or purchase and appropriately modify) the switching modules together with the software 
and the cost of modifying NADIN concentrator software. The former would cost 
approximately $75,000 per module; the latter, including major testing and debugging, is 
estimated to cost approximately $1.2 million. 

Based on the above considerations, the one-time costs associated with Alternative 3 
would include: 

• switching module costs, including software, 

• modem costs, 

• installation costs for 28 new channels, 

• NAS 9020 software modification costs (assumed to be equal to those for 

Alternative 2), and 

• NADIN software modification costs. 

The one-time cost (OC) for Alternative 3 would thus be determined as shown below: 


Switching Module 

20 x $75,000 

= 

$ 1,500,000 

Modems 

2 x 15 x $8,500 

= 

255,000 

Station Installation 

28 x 2 x $57 

= 

3,192 

Conditioning Installation 

28 x 2 x $171 

= 

9,576 

9020 Software 

400 x $150 

= 

60,000 

NADIN Software 


= 

1,200,000 


OC 

= 

$ 3,027,768 


As suggested earlier, the recurring cost has been determined by considering the 
monthly charges for the full, modified network and reducing these by the similar charges 


4-16 









that would be incurred if the unmodified NADIN IA were retained. For the reconfigured 
network the gross recurring cost (GRC) would be determined as shown below: 

Fixed Charge : 37 x $51.72 = $ 1,914 

IXC (see Table 4-3) : = 13,620 

Drop Charge : 37 x 2 x $26.30 = 1,946 

Conditioning Charge : 37 x 2 x $15.50 = 1,147 

GRC = $ 18,627 

For the unmodified NADIN IA, the base recurring cost (BRC) would be determined as shown 
below: 


Fixed Charge : 22 x $51.72 = $ 1,138 

IXC (see Table 4-2) : = 11,249 

Drop Charge : 22 x 2 x $26.30 = 1,157 

Conditioning Charge : 22 x 2 x $15.50 = 682 

BRC = $ 14,226 


The net recurring cost (RC) would then be: 

RC = GRC - BRC 

= $18,627 - $14,226 = $4,401 

The present value (PV) of the recurring charges would be : 

PV = $4,401 x 77.0 = $338,877 

The life-cycle cost (LC) would be 

LC = $3,027,768 + $338,877 = $3.37 million 
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LINK NODES 

DISTANCE 

(MILES) 

CHANNELS 

IXC 

;S/month 

Seattle 

Oakland 

675.2 

1 

S 529.51 

Seattle 

Salt Lake City 

684.4 

1 


Oakland 

Los Angeles 

323.0 

1 

29b. 5 v. 

Los Angeles 

Salt Lake City 

589.7 

1 

470.60 

Los Angeles 

Albuquerque 

671.1 

1 

l 

526.70 

Salt Lake City 

Albuquerque 

485.8 

1 

398.90 

Salt Lake City 

Denver 

359.4 

2 

623.30 

Denver 

Albuquerque 

361.6 

1 

313.20 

Oenver 

Minneapolis 

684.9 

1 

536.20 

Denver 

Kansas City 

555.8 

2 

894.30 

Albuquerque 

Fort Worth 

568.9 

1 

456.20 

Kansas City 

Minneapolis 

408.3 

1 

345.40 

Kansas City 

Fort Worth 

437.2 

1 

365.40 

Minneapolis 

Chicago 

314.2 

1 

280.50 

Chicago 

Indianapol is 

177.9 

2 

372.80 

Kansas City 

Memphis 

369.3 

1 

318.50 

Fort Worth 

Houston 

222.5 

1 

217.20 

Houston 

Memphis 

473.1 

1 

390.10 

Indianapolis 

Cleveland 

232.3 

1 

223.90 

Indianapo!is 

Atlanta 

454.2 

2 

754.10 

Memph i s 

Atlanta 

702.2 

2 

611.80 

Houston 

Miami 

972.2 

1 

734.50 

Atlanta 

Cleveland 

558.7 

1 

449.20 

Atlanta 

Washington 

545.4 

1 

440.00 

Atlanta 

Jacksonvi lie 

232.3 

2 

447.90 

Cleveland 

Boston 

561.7 

1 

451.30 

Cleveland 

Washington 

288.0 

1 

262.40 

Washington 

New York 

264.3 

1 

246.00 

New York 

Boston 

158.7 

1 

173.20 

Jacksonvi1le 

New York 

857.3 

1 

655.20 

Jacksonville 

Mi ami 

356.3 

1 

309.50 

TOTALS 

37 

$13,620.00 


TABLE 4-3: INTEREXCHANGE MILEAGE CHARGE (IXC), ALTERNATIVE 3 
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4.4.3 Alternative 3 Back-Up Service 

Alternative 3 requires no separate back-up service. Should one link be lost, the packet 
routing/switching function will find an alternate route and insure that no links are 
overloaded. The network delays under such circumstances might be slightly greater than 
when all links are functioning, but generally there should be no significant degradation in 
service quality. 

The fact that this alternative generally requires the use of two or more links for a 
connection does increase the likelihood that a specific primary route is lost, as compared 
with the single link, redundant NAS-NAS Network. Nevertheless, the availability of 
alternate routes and the geographical distribution of the links make it less likely that a 
connection would be totally lost. The NAS-NAS Network, on the other hand, is more 
susceptible to complete loss of a (redundant) connection as the result of storms or other 
external causes. 

4.4.4 Alternative 3 Long-Range Potential 

Alternative 3 offers the same longer-range benefits as Alternative 2; i. e., reduced 
computer interfaces and interconnection between all centers. Alternative 3 can, however, 
provide generally better support to the Center Back-Up concepts in that: 

• it is less dependent on routes through the two centralized message-switch nodes, 

• it provides more direct connections between neighboring centers, and 

• it is less susceptible to link congestion. 


4.5 ALTERNATIVE 4, NAS-NAS/NADIN IA 

Alternative 4 combines the small network delays of the current NAS-NAS Network 
with the reduced cost of using NADIN. Specifically, this alternative retains one channel on 
each of the 45 NAS-NAS links and uses NADIN (as configured under the Level IA implemen¬ 
tation) as a back-up in the event of NAS-NAS Network link outage. An operational variation 
on this alternative would involve the use of NADIN as the primary communications service 
and the use of NAS-NAS links only during periods when NADIN delays are too great or when 
there is a NADIN link outage. 
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4.5.1 Alternative 4 Throughput Performance 

The throughput performance under Alternative 4 would be essentially the same as that 
under Alternative 1. 

4.5.2 Alternative 4 Costs 


It is assumed that under Alternative 4 there would be no significant modifications to 
NADIN IA. NAS 9020 software would, however, have to be modified, essentially as with 
Alternative 2. Thus the one-time cost (OC) for this alternative would be determined as 
shown below: 

Software : 400 x $150 = $60,000 


OC = $60,000 

The recurring costs for Alternative 4 would be similar to those for Alternative 1, 
however each link would now include only a single channel. Thus the recurring cost (RC) 
would be determined as shown below: 


Fixed Charge : 45 x $51.72 = $ 2,327 

IXC (see Table 4-1) : = 18,746 

Drop Charge : 45 x 2 x $26.30 = 2,367 

Conditioning Charge : 45 x 2 x $15.50 = 1,395 


RC = $ 24,835 


The present value <PV) of the recurring costs would thus be: 

PV = $24,835 x 77.0 = $1,912,295 

The life-cycle (LC) cost would be : 


LC 


$60,000 + $1,912,295 


$1.97 million 






4.5.3 Alternative 4 Back-Up Service 


The back-up service under Alternative 4 is NADIN IA. Although this is better than the 
Alternative 1 manual back-up service, it is more likely to be used because of the absence of 
link redundancy. The quality of this back-up service is generally good; however, it is subject 
to congestion, if required during a peak period. 

4.5.4 Alternative 4 Long-Range Potential 

Alternative 4 offers some improvement in terms of long-range potential relative to 
that under Alternative 1. It involves only half as many interfaces with the NAS 9020 
computers, and it provides, through NADIN IA, interconnections between all centers. The 
fact that some NAS-NAS interfaces would still exist and that NADIN link capacities would 
not be increased, limit the long-range value of the improvements. 


4.6 ALTERNATIVE 5, REDUNDANT NADIN IA 

Alternative 5 is essentially the same as Alternative 2, except that one back-up channel 
would be added to each of the 21 NADIN links. This would improve service when primary 
channels experience outages. Except for this improved back-up service, there would be no 
significant change in performance. 

4.6.1 Alternative 5 Throughput Performance 

Under the basic concept of this alternative, the throughput performance would be 
identical with that of Alternative 2. It should be possible, however, with minimal additional 
software modifications to permit use of the redundant line at any time, thus further 
reducing queueing delays, especially during temporary surges in traffic. 

4.6.2 Alternative 5 Costs 


The only differences in cost between Alternatives 2 and 5 would be the added costs of 
installation (including modem purchase) and operation for the 21 back-up channels under 
Alternative 5. The added one-time costs (AOC) would be determined as below: 








Modems 

: 21 x 2 x $8,500 

= 

$ 

357,000 

Station Installation 

: 21 x 2 x $57 

= 


2,394 

Conditioning Installation 

: 21 x 2 x $171 

= 


7,182 


AOC 

= 

$ 

366,576 


The added channels for this alternative basically duplicate the unmodified NADIN 1A 
channels, except for the switch-to-switch link. Thus the added IXC for Alternative 5 would 
be equal to that shown for NADIN IA in Table 4-2 minus half the IXC for the 
switch-to-switch link (i.e., $2,010.90*2 = $1,005). The added recurring cost (ARC) for 
Alternative 5 would be determined as shown below: 

Fixed Charge : 21 x $51.72 = 

IXC : $11,249 -$1,005 = 

Drop Charge : 21 x 2 x $26.30 = 

Conditioning Charge : 21 x 2 x $15.50 = 

ARC 

The added present value (APV) of the recurring costs would be: 

APV = $13,086 x 77.0 = $1,007,622 

The added life-cycle cost (ALC) would be: 

ALC = AOC + APV 

= $366,576 + $1,007,622 = $1.37 million 

The total life-cycle cost (LC) would be obtained by adding the above result to the life-cycle 
cost for Alternative 2 ($.97 million), i.e.: 

LC = $.97 million + $1.37 million = $2.34 million 


$ 1,086 
10,244 
1,105 
651 


$ 13,086 
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4.6.3 Alternative 5 Back-Up Service 


This alternative, like Alternative 1, uses redundant lines to minimize the likelihood of 
having to use the back-up service. Thus these two alternatives can be rated equivalently in 
this respect. 

4.6.4 Alternative 5 Long-Range Potential 

The long-range potential of this alternative is the same as that for Alternative 2. 



SECTION 5 


COMPARATIVE EVALUATION 


5.1 INTRODUCTION 


On the basis of cost alone, the preceding analysis indicates that the most efficient 
approach to supporting NAS-NAS communications would involve the use of NAD1N IA, 
enhanced to provide greater link capacities (Alternative 2). The more subjective portions of 
that analysis indicate, however, that the higher costs for the other alternatives are 
generally associated with additional benefits. This appears particularly true for the 
Enhanced NADIN Architecture (Alternative 3). 

5.2 COST AND BENEFIT COMPARISONS 


The five alternatives considered for supporting NAS-NAS communications have been 
analyzed relative to four major areas of differences. These are: 

• cost, in terms of the ten-year life cycle cost; 

• throughput performance, reflecting primarily the ability to effectively handle 
temporary surges in demand; 

• back-up service, reflecting the quality of the back-up service provided and the 
likelihood that it would be needed; and 

• long-range potential, reflecting primarily the ability to facilitate and/or support 
the objectives of the ATC Computer Replacement Program and Center Back-Up 
concepts. 

Relative to all four considerations, no one of the five alternatives stands out as the 
ideal selection. Each has its advantages and disadvantages. These are summarized in 
Table 5-1. 




























In order to provide a more objective basis for comparison, judgemental values have 
been assigned for the three subjective areas, using 10 to represent "the best". The assigned 
ratings for each alternative are shown in Table 5-2 along with the associated cost. 

5.3 INTERPRETATION OF RESULTS 


Review of the results as presented in T«» k 1p c -2 reveal the following: 

1. The major weakness of the current NAS-NAS network (Alternative 1), relative to 
the use of NADIN, is its low long-range potential. It is also the most expensive 
of the alternatives considered. 

2. For approximately the same cost as the current network, the Enhanced NADIN 
Architecture (Alternative 3) can provide essentially equivalent service quality 
plus a major increase in long-range potential. 

3. The three other alternatives involving the use of NADIN (Altrenatives 2, 4 and 5) 
can all support the basic NAS-NAS requirements at significantly reduced costs. 
Each of these, however, would involve giving up other nice-to-have features 
when compared with Alternative 3. Only the redundant NADIN IA 
(Alternative 5), the most expensive of the three, can be considered to provide 
service (throughput performance and back-up service) close to that of the 
current network, plus a long-range potential close to that of Alternative 3. 

Item 2 above suggests that use of NADIN would be preferred over continued use of the 
current NAS-NAS Network. Item 3 above suggests that the best NADIN alternative depends 
on the cost-benefit trade offs. Such trade offs must be determined on a subjective basis, 
and can best be determined by FAA personnel more familiar with FAA priorities. 

There are, however, certain considerations that suggest Alternative 3 as the most 
cost-beneficial approach. These include: 

• The cost of the current NAS-NAS Network is not felt to be unreasonably high for 
the service quality provided. Thus cost is probably one of the least important of 
the factors considered. 
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SUBJECTIVE RATINGS* 

ALTERNATIVE 

COST 

(mi 1 lions) 

THROUGHPUT 

PERFORMANCE 

BACK-UP 

SERVICE 

LONG-RANGE 

POTENTIAL 

1. Current 
NAS-NAS 
Network 

S3.82 

10 

8 

2 

2. Enhanced 

NADIN IA 

.97 

6 

5 

6 

3. Enhanced 

NADIN 

Architecture 

3.37 

9 

10 

10 

4. NAS-NAS/ 

NADIN IA 

1.97 

10 

6 

4 

5. Redundant 

NADIN IA 

2.34 

8 

8 

6 


♦Higher rating values = more desirable qualities. 


mUrlL. '’STS AND SUBJECTIVE RATINGS FOP. NAS-NAS SERVICE ALTERNATIVES 
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• Alternative 3, more than any of the other NADIN alternatives considered, would 
provide the capability to support other more demanding FAA programs and 
communications requirements. Thus a smaller portion of the cost for 
Alternative 3 could be considered as being associated strictly with NAS-NAS 
service. This concept of sharing the cost can best be evaluated through an 
integrated study (such as is planned under Task 13). 

5.4 OTHER CONSIDERATIONS 

The evaluations above primarily suggest a general preference for NADIN over the 
current NAS-NAS Network. The identification of Alternative 3 as the most attractive of 
the four NADIN alternatives was based primarily on the long-range potential, especially the 
potential for supporting the ATC Computer Replacement Program and subsequent modifica¬ 
tions of the computer system. Since the current NAS-NAS Network is expected to provide 
highly satisfactory service prior to computer replacement, there is no pressing requirement 
to replace that service. Rather, it would appear to be primarily important that any change 
in the service occur prior to computer replacement. 

Further, since the advantages of Alternative 3 relate to its ability to support computer 
replacement and other FAA programs, it would be desirable that Alternative 3 be further 
tailored to insure more optimal support for those programs. Information pertinent to this is 
expected to be developed through three other tasks under this contract (Tasks 12, 13 
and 14). It would thus appear prudent to delay any major activity to replace the current 
NAS-NAS Network until at least preliminary results are available from those studies. 

In anticipation of implementing Alternative 3, or a variation of that concept, there are 
some areas of more detailed study that should be addressed. These include: 

• an analysis of the feasibility and cost for converting the NADIN concentrators 
into combined concentrator/packet-switch units; 

• a survey of other available hardware and software to support -a<. -switching 
networks of the type considered; 






• an analysis of the impact on NADIN traffic in general that would result from the 
provision of special handling for selected message classes (including use of 
permanent virtual circuits for specific message classes); and 

• a detailed consideration of the transition process from NADIN IA to the packet¬ 
switching enhancement. 
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APPENDIX A 


ANALYSIS FOR ALTERNATIVE 2 


A.l PURPOSE AND SCOPE 


This appendix investigates network delay times for NAS-NAS messages, should 
Alternative 2 be adopted, and determines modifications necessary to insure that delay 
constraints are met. It includes the assumptions, methodology and data used. This analysis 
has drawn heavily on the methodology and data presented in the Technical Data Package for 
NADIN Level IA (Reference 9, referred to hereafter as the Level IA Study). 

A.2 GENERAL APPROACH 


Under Alternative 2, NADIN, essentially as configured for NADIN IA, would be used as 
the communications utility for NAS-NAS message traffic. Thus the traffic between two 
centers would be routed from the NADIN concentrator collocated with the sending 
NAS 9020 computer, to the associated NADIN switch, and then to the NADIN concentrator 
collocated with the receiving NAS 9020 (possibly through the other NADIN switch). 

For this analysis the 1983 peak-period NADIN message traffic identified in the 
Level IA Study has been assigned to specific NADIN backbone links. The projected 1983 
NAS-NAS traffic has similarly been assigned to pertinent links. The effect of these 
cumulative throughput requirements on NAS-NAS message delays has been determined, 
using standard queueing models. Finally, the throughput growth by 1988 has been estimated 
and its effect on delays also determined. 

In carrying out this analysis, the following assumptions have been used: 

1. NADIN will be implemented with the double-star backbone configuration, 
illustrated in Figure A-l, by early 1983. 
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2. Under the Level IA implementation, each NADIN switch-to-concentrator trunk 
will be a full-duplex, voice-grade channel operating at 9,600 bits per 
second (b/s). The switch-to-switch trunk will consist of two such channels. 

3. A switch discipline will be implemented that will prevent the transfer of large 
files from unduly delaying the transmission of other messages (as suggested in 
the Level LA Study and Reference 14). In addition, efforts will be made to 
restrict the number of file transfers that occur during the same hour, through 
optimal scheduling of transfers that are required less frequently than once an 
hour. 

4. In addition to the NAS-NAS traffic, NADIN backbone links will be used to 
transmit the following types of message traffic: 

• NADIN I - The traffic specified for initial NADIN implementation (see 
Appendix Z, Reference 6), including primarily that traffic currently 
handled by the Area B/Supplemental B, Airline and Military Utility B, 
Center B, AFTN and NASNET networks; 

• AFC - Messages disseminated from the Interim Flow Control Processor 
(IFCP) in Jacksonville (to ARTCCs, terminal areas, FSSs, ARINC and 
airlines) under the Interim Automated Flow Control program and flight 
data messages forwarded from the ARTCCs to the Central Flow Control 
Computer Complex (CFCCC) in Jacksonville (see Reference 15); 

• FSAS - All message and file transfers identified for the Flight Service 
Automation System (see Reference 14); 

• NFDC/IS - NC iMs and interactive messages transferred between the 
National Flight Data Center (NFDC) in Washington and the Consolidated 
NOTAM System (CNS)/Airmen Information System (AIS) in Atlanta; plus 
NOT A Ms transferred between the CNS and a back-up NOTAM processor in 
Salt Lake City (see Alternative 2 in Reference 16). 
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NADIN will also be used for other message traffic. However, such traffic will 
not use the backbone links; e.g.: 


• FDIO (FDF.P) messages will be locally switched by each NADIN concen¬ 
trator (as suggested in the Level 1A Study and Reference 7), and; 

• All traffic between CNS and AWP/WMSC will involve only the NADIN 
Atlanta switch; collection and distribution of NOTAMs from or to other 
locations is included in the FSAS and Service A message traffic (the latter 
is not considered to be integrated into NADIN). 

6. NADIN backbone traffic to and from the three off-shore centers (Anchorage, 
Honolulu and San Juan) will have negligible impact on NADIN's performance 
relative to NAS-NAS message traffic. 

7. Between the Level 1A implementation (1983) and 1988, NADIN message traffic 
will increase in proportion to the projected increase in IFR aircraft traffic; this 
has been conservatively estimated to be 22 percent. 

A.3 THROUGHPUT REQUIREMENTS 

Peak-period throughput requirements, measured in bits per second (b/s), have been 
determined for each NADIN backbone link. These represent the accumulated requirements 
of the four traffic categories identified above, plus the NAS-NAS requirements. The 
requirements have been calculated in two forms: 

► • Net throughput (NT) - the bits representing original messages that are to be 

transmitted per second, and 

• Gross throughput (GT) - the total number of bits, including all overhead 
transmissions, that are to be transmitted per second. 

Both requirements are calculated from the average message length (L, measured in 
characters per message) and the peak-period message frequency (F, measured in messages 
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per hour). Net throughput is the product of these two message characteristics, with 
appropriate conversion of units, i.e.: 


NT = F x L x B/S 

where B = 8 = the number of bits per character, 

S = 3600 = the number of seconds per hour. 


Thus: 


NT = .002222 x F x L 

Gross throughput reflects the addition of all other bit, character and message 
transmissions required by the network (NADIN) or link (ADCCP) protocols. These have been 
detailed in the Level IA Study and are summarized below: 

• NADIN requires a header and trailer on each "message". Together these involve 
approximately 63 characters. A NADIN message is limited to 3700 characters. 
Thus, any actual message or file which contains more than 3700 characters must 
be broken down into two or more NADIN messages, with a header and trailer 
added to each. 

• Messages are transmitted across the individual NADIN backbone links in frames 
with 245 or less characters. ADCCP adds frame control data, equivalent to 
11 characters for each frame, and inserts additional zero bits to avoid ambiguity 
between data and synchronization bit strings. It has been determined that the 
zero insertion process increases the number of bits (and hence the number of 
equivalent characters) by about 1.6 percent. 

• Both the network and link protocols transmit control messages on the lines. It 
has been estimated that each adds the equivalent of 3 percent to the 
transmissions. 
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• Finally, the control procedures cause the automatic retransmission of frames 
containing transmission errors. It has been conservatively estimated that 
2.5 percent of all frames must be retransmitted. 

Taking these overhead items into consideration, the gross message length (GL) and 
gross message frequency (GF) are determined from: 

GL = [L + (a x 63) + (b x 11)] x 1.016 

where a = the smallest integer ^L/3700, 

b = the smallest integer^[L + (ax 63)]/245. 

GF = F x 1.03 x 1.03 x 1.025 

= 1.087 x F. 

The gross throughput is calculated as: 

GT = GF x GL x B/S 

= .00245 F x [L + (a x 63) + (b x 11)] 

The message characteristics and associated 1983 throughput requirements for the five 
traffic categories considered are presented in the following subsections. 

A.3.1 NADIN I Traffic 


The Level IA Study used the design parameters from the NADIN Specifications 
(Appendix Z, Reference 6) as the basis for NADIN I throughput requirements. That study 
modified only the Area B message frequencies, to reflect more recent data. Those same, 
modified traffic characteristics have been used in this analysis. Not included in those data, 
are the requirements for the collection of flight data from ARTCCs for flow control 
purposes. This function is now considered part of the NADIN I requirements. For 
convenience in this study, those requirement? re considered under AFC Traffic. 


A-6 









The nature of the NADIN I design data makes it impractical to differentiate the 
requirements for individual backbone links. Rather, the requirements have been distin¬ 
guished only in terms of three types of transmissions: 

• concentrator-to-switch, 

• switch-to-concentrator, and 

• switch-to-switch. 


Table A-l shows the message characteristics and the associated peak-period through¬ 
put for each of these types of transmission. 

A.3.2 AFC Traffic 

The study of Automated Flow Control (AFC) communications requirements 
(Reference 15) was being carried out simultaneously with the Level IA Study. As a 
consequence the Level IA Study reflected preliminary data and findings relative to the AFC 
message traffic. The data used below differ from that in the Level IA Study in three 
respects: 

• treatment of the increase in number of pacing airports, 

• consideration of flight data collection messages (as part of NADIN I) in addition 
to the dissemination of flow control messages (as part of NADIN IA), and 

• minor revisions to the flow control message frequencies. 

A.3.2.1 Pacing Airports 

Flow control message traffic is concerned primarily with air traffic at selected busier 
airports, called pacing airports. Currently there are 17 pacing airports. This number is 
expected to increase to 35, sometime between 1983 and 1988. This increase is conserva¬ 
tively assumed to cause a doubling in AFC message traffic, in addition to increases caused 
by air traffic growth. 






NADIN BACKBONE LINK MESSAGE CHARACTERISTICS PEAK THROUGHPUT (B/S) 

FROM TO MSG./HR. MEAN CHAR. NET GROSS 



TABLE A-1: NADIN I PEAK PERIOD MESSAGE TRAFFIC 

























For this analysis it is convenient to reflect the impact of the additional pacing airports 
in the 1983 data. Growth in NADIN throughput requirements for subsequent years can then 
be considered uniform across the various message traffic categories. 

A.3.2.2 Flight Data Collection Messages 

Flight data messages are currently directed from the NAS 9020 computers at the 20 
CONUS ARTCCs to the CFCCC in Jacksonville over a hybrid store-and-forward network. 
That network utilizes selected links of the NAS-NAS Network to transmit the messages to 
the NAS 9020 computers at five ARTCCs (called forwarding centers). These five computers 
are linked directly to the CFCCC. Under the NADIN I implementation the CFCCC will be 
directly connected to the Atlanta switch. Flight data messages will then be transmitted 
from each NAS 9020 computer to the collocated NADIN concentrator and then to the 
CFCCC over the NADIN backbone links. 

Flight data message characteristics are shown in Table A-2. That table includes two 
groups of messages: 

• Present Messages, i.e., those currently transmitted over the store-and-forward 
network, and 

• Future Messages, i.e., those additional messages to be included in the flight data 
collection process in future years. 

As with the increase in number of pacing airports, this analysis includes the "future" 
messages as part of the 1983 throughput requirements. 

The baseline (1980) message frequencies have been obtained from Reference 15. The 
projected 1983 peak period frequencies have been determined by first doubling the baseline 
frequencies to reflect the increased number of pacing airports, and then considering a 
3 percent annual growth; i.e.: 

Adjustment Factor = 2 x (1.03)^ = 2.185 
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The data in Table A-2 reflects the cumulative messages arriving at the CFCCC. The 
fraction of messages that originate at each ARTCC is shown in Table A-3 (based on data in 
Reference 15) along with the associated message frequency. 

The association of this traffic with specific NADIN backbone links is relatively direct. 
Traffic originating at a specific concentrator will exist on the link from that concentrator 
to the associated switch (indicated in Table A-3). The sum of all such traffic directed to the 
Salt Lake City switch will also exist on the Salt Lake City to Atlanta link. This traffic 
distribution and the associated throughput requirements are shown in Table A-4. In this and 
subsequent tables, the NADIN links are identified by the interconnected nodes, using the 
symbols defined in Table A-3. 

A.3.2.3 Flow Control Dissemination Messages 

The flow control message traffic expected to be carried by NADIN is characterized in 
terms of three message types, all originating or terminating at the IFCP in Jacksonville. 
These are identified in Table A-5. Message frequencies shown in that table reflect the 1980 
baseline values (from Reference 15) and the projected 1983 values, obtained by use of the 
2.185 adjustment factor discussed earlier. They apply directly only to messages leaving or 
arriving at the IFCP. 

The distribution of this message traffic among the NADIN links has been estimated 
using the following procedures and assumptions: 

1. The IFCP will interface NADIN at the Jacksonville concentrator. Thus the 
Jacksonville-to-Atlanta link will carry all the Type 1 and Type 2 traffic 
indicated in Table A-5, plus that portion (5 percent) of the Type 3 messages that 
originates at the Jacksonville ARTCC. 

2. It has been estimated that each Type 1 and Type 2 message leaving the IFCP, 
destined for ARTCCs and ATCTs, will be addressed to an average of five 
destinations. The necessary duplication will be effected at the Atlanta switch. 
Thus there will be five times as many Type 1 and Type 2 messages for such 
destinations leaving the Atlanta switch as leaving the Jacksonville concentrator. 
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ARTCC/CONCENTRATOR 

FRACTION OF 
FLIGHT DATA 
MESSAGE ORIGINS** 

1983 

PEAK 

MSG./HR. 

SYMBOL 

LOCATION 

SWITCH* 

ZAB 

Albuquerque 

XLC 

.0A8 

766 

ZTL 

Atlanta 

XTL 

.055 

378 

ZBW 

Boston 

XTL 

.035 

559 

ZAU 

Chicago 

XTL 

.053 

846 

ZOB 

Cleveland 

XTL 

.079 

1,261 

ZDV 

Denver 

XLC 

.046 

734 

ZFW 

Fort Worth 

XLC 

.049 

782 

ZHU 

Houston 

XLC 

.036 

575 

ZID 

Indianapolis 

XTL 

.078 

1,245 

ZJX 

Jacksonvi 1 le 

XTL 

.081 

1,293 

ZKC 

Kansas City 

XLC 

.057 

910 

ZLA 

Los Angeles 

XLC 

.030 

479 

ZME 

Memphis 

XTL 

.067 

1,069 

ZMA 

Miami 

XTL 

.047 

750 

ZMP 

Minneapolis 

XTL 

.046 

734 

ZNY 

New York 

XTL 

.055 

878 

ZOA 

Oakland 

XLC 

.029 

463 

ZLC 

Salt Lake City 

XLC 

.016 

255 

ZSE 

Seattle 

XLC 

.031 

495 

ZDC 

Washington 

XTL 

.061 

974 


* Symbol indicates associated NADIN switches, as follows: 

XLC = Salt Lake City switch 
XTL = Atlanta switch 

** Source: NAC WM.303G.02 AFC Requirements Analysis, December 30, 1980. 
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ARINC and airlines will interface NADIN at the Atlanta switch. Thus messages 
to those destinations will use only the Jacksonville to Atlanta link. 


4. Three NADIN concentrators (New York, Chicago and Washington) receive 
significantly more of the messages than the other 17 CONUS concentrators. It is 
estimated that 11.54 percent of the Type 1 and Type 2 messages leaving the 
Atlanta switch are routed through each of the three "busier" concentrators and 
3.85 percent are routed through each of the other seventeen (a 3-to-l ratio). As 
a result, 9 x 3.85 = 34.6 percent are routed from the Atlanta switch to the Salt 
Lake City switch. 

5. The origins of Type 3 messages are assumed uniformly distributed with respect 
to the 20 concentrators. Thus, 5 percent of the Type 3 messages will enter 
NADIN through each concentrator and 9 x 5 = 45 percent will be routed from the 
Salt Lake City switch to the Atlanta switch. All Type 3 messages plus the 
appropriate share (3.85 percent) of Type 1 and Type 2 messages will be routed 
from the Atlanta switch to the Jacksonville concentrator. 

The results of this distribution process are shown in Table A-6. 

A.3.3 FSAS Traffic 

The FSAS throughput requirements have been taken from the Level IA Study (as 
summarized from Reference 14). In distributing these requirements to individual NADIN 
links, three categories of messages have been considered: 

• file transfers, 

• messages to and from ARO, and 

• all other messages. 

Thirteen types of file transfers have been identified. These are indicated in 
Table A-7. All thirteen are transferred from each of the two AWPs (collocated with the 
NADIN switches) to each associated FSDPS (one collocated with each NADIN concentrator). 
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TABLE A-7: AWP-TO-FSDPS FILE TRANSFERS 

















In addition, four of the same files (identified by the Table A-7 footnote) are also transferred 
between the AWPs. 

Unlike other message traffic which occurs essentially at random, the file transfers are 
scheduled. Thus, a file which is transferred once an hour will be transferred exactly once 
during a peak hour. A file transferred once every eight hours may or may not be transferred 
during n peak hour. If the file transfers could be scheduled so that approximately the same 
number of file characters (over a number of different files) could be transferred each hour, 
the average message frequency shown in Table A-7 could be used to determine peak 
throughput. Such an assumption would be too optimistic for this analysis. Rather, it has 
been conservatively assumed that the effective message frequency during the peak period is 
twice the average for those files scheduled for transfer less frequently than once an hour. 
This is indicated by the Peak Adjustment Factor in the table, and is reflected in the 
throughput requirements shown. 

The Airport Reservation Office is assumed to interface NADIN via the Jacksonville 
concentrator. Thus messages from an FSDPS to ARO will be routed from the concentrator 
collocated with the FSDPS, to the associated switch, across the switch-to-switch link, if 
necessary, and then from the Atlanta switch to the Jacksonville concentrator. All messages 
from ARO to an FSDPS would follow the reverse route. ARO message traffic is assumed to 
be approximately the same for each FSDPS. Thus the data from the Level IA Study (and 
Reference 14) have been used for each link between a switch and concentrator (other than 
the Atlanta/Jacksonville link). The switch-to-switch traffic and the Atlanta/Jacksonville 
link traffic have been determined by the appropriate aggregation of all messages using those 
links. 

Data for other FSAS message traffic identified in the Level IA Study have been used 
directly, assuming essentially the same level of traffic between each FSDPS and associated 
AWP. The message characteristics and resultant throughput requirements for all three 
categories of messages are shown in Table A-8. 

A.3.4 NFDC/IS Traffic 

The NFDC/IS throughput requirements considered, reflect primarily the implemen¬ 
tation of Alternative 2 from the Communications Support Study for NFDC/IS 
(Reference 16). That alternative considers the use of NADIN backbone links only for (non¬ 
batch) communications between NFDC, connected to the Washington concentrator, and 
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TABLE A-8: FSAS PEAK PERIOD MESSAGE TRAFFIC (Page 1 of 2) 
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CNS/AIS, connected to the Atlanta switch. Characteristics of that traffic have been taken 
directly from the referenced study. 

Subsequent to the referenced study, consideration has been given to the use of a 
back-up NOTAM processor in Salt Lake City. Estimates of the message traffic between 
CNS and the back-up processor (switch-to-swiftch) were included in the Level IA Study. In 
order to ensure a conservative estimate of switeh-to-switch throughput requirements, those 
estimates have been included in this analysis also. Table A-9 summarizes the message 
characteristics and throughput requirements on the pertinent NADIN links. 

A.3.5 NAS-NAS Traffic 

NAS-NAS traffic characteristics have been developed on an origin-destination basis 
(see Section 2 of this report). Since the origins and destinations for this traffic are the 
NAS 9020 computers collocated and interfaced with the 20 CONUS NADIN concentrators, 
the traffic can be directly assigned to the specific links. Table A-10 shows the accumulated 
NAS-NAS traffic characteristics and throughput requirements for each NADIN link. 

A.3.6 Total Throughput 

The gross throughput requirements presented above for the various types of traffic are 
tabulated for each of the 21 NADIN links in Table A-ll. That table also shows the total 
requirements for each direction on each link. 

The line utilization (U) implied by these results is determined as: 

U = CGT/C 

where C = the line capacity, in bits per second, 

= 9,600 b/s for links between a switch and concentrator, 

= 19,200 b/s for the switch-to-switch links, 

and CGT = the cumulative gross throughput on the link. 

Table A-12 shows the throughput requirements and utilization for the ten busiest links. 
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TABLE A-10: NAS-NAS PEAK PERIOD MESSAGE TRAFFIC (Page 1 of 2) 


























TABLE A-10; NAS-NAS PEAK PERIOD MESSAGE TRAFFIC (Page 2 of 2) 

















































.-12: UTILIZATION OF BUSIEST NADIN LINKS 


















A.4 NETWORK DELAYS 


Delays encountered by NAS-NAS messages on NADIN fall into three major categories: 

• queueing delays for each link used, 

• transmission time on each link, and 

• node processing delays. 

The total network delay (TD) would thus be calculated as: 

n 

m, (TQ. + TM.) + (n+1) x TN 
i=l 1 1 

the queueing delay on link i, in seconds, 

the NAS-NAS message transmission time on link i, in seconds, 
the processing time per node, in seconds, and 

the number of NADIN backbone links involved in the transmission 
(2 or 3 for NAS-NAS messages). 

The processing delay per node is conservatively estimated to be 50 milliseconds, i.e.i 

TN = .05 seconds 

The transmission time is determined from: 

TMj = GL x B/C. 

where CL is the transmission rate (capacity) on link i, in bits per second, 

and GL and B are the gross message length and bits per character as discussed earlier. 


TD = 
where TQ. = 

TM. = 

l 

TN = 

n = 
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For the links between a switch and concentrator, C. = 9,600 b/s. On the switch-to-switch 
link, although the effective capacity is 19,200 b/s, a given message will always be 
transmitted over a single 9,600 b/s channel. Hence, = 9,600 b/s for the dual-channel link 
also. Thus, for NAS-NAS messages, which have a mean length of 37.7 characters: 

TMj = (37.7 + 63 +11) x 1.016 x 8/9,600 = .09 seconds, for all links 

Using the above results, the network delay can be expressed as: 

n 

TD = (n x .09) + (n + 1) x .05 + ]C TQ. 

i=l 1 

n 

= .47 + £ TQ., if n = 3 

i=l 1 

n 

= .33 +X) TQ., if n = 2 

i=l 1 

Determination of the queueing delays requires the consideration of several variations. 
Primary among these is the presence or absence of files to be transferred. Another 
important variation is the use of single or dual transmission channels. The procedures used 
to estimate the queueing delays are based on the analyses detailed in Reference 14. 

A.4.1 Queueing Delays in the Absence of File Transfers 

On links involving no file transfers, messages can be assumed to arrive at random. For 
the single-channel links, the queueing delay will be approximately: 

TQ. = TF. x U./U-Uj) 

where TFj = the average transmission time, in seconds, per frame on link i, 

= GLF x B/C. 

GLF = the gross length, in characters, of an average frame, 

and Uj, Cj and B are the link utilization, link capacity and bits per character, as 
discussed earlier. 
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As a conservative estimate, a full frame (245 characters) is considered in estimating 
TF- Thus: 

GLF = (245 + 11) x 1.016 = 260 characters 

TF. = 260 x 8/9,600 = .22 seconds 

U. = CGTj/9,600 

Uj/d-Uj) = CGTj/(9,600-CGT.) 


TQ. = .22 x CGT./(9,600-CGT.) seconds, for the single-channel links. 

The above approximation assumes random (Poisson) message arrivals and a standard 
deviation of frame length that is equal to the average frame length (a conservative 
assumption). The bases for this approximation can be found in most queueing theory texts 
(see, for example, Reference 17, Chapter 3). 

Files will be transferred in both directions on the dual-channel switch-to-switch link. 
Peak-period queueing delays for those links would thus be determined as discussed below. 

A.4.2 Queueing Delays in the Presence of File Transfers 

The relatively large file (or report) transfers introduced by FSAS and AFC traffic can 
create intervals of several minutes during which a link will be transmitting at essentially 
full capacity. The assumption of random message arrival, used above, is therefore not 
applicable during such intervals. These intervals will be the real peak periods for NADIN. 

As recommended in the Level IA Study (and Reference 15), it is assumed that a 
discipline will be implemented at the NADIN switches, such that large file transfers will not 
unduly delay other message traffic. This has been modeled as follows: 

• Consider the NADIN backbone link connecting a switch (Node A) and an 
associated concentrator or the other switch (Node B). For this link, Node A will 
effectively maintain a number of output message queues, one for each output 
port at Node B (plus a top priority message queue, which need not be considered 
here). 


A-30 









• The discipline at Node A will cycle through the queues for Node B, processing 
each queue in turn. 

• If a queue (Queue I) is empty, it is instantly passed over. 

• If Queue I is not empty, one frame from that queue is transmitted to Node B and 
processing passes to Queue I + 1. Any other message frames in Queue I must 
await processing in subsequent cycles. 

The mean queueing delay for the first or only frame in a randomly arriving message, 
under such a process can be determined approximately as: 

TQj = .75 x TCj 

where TCj = mean time per cycle through the queues for link i. 

TC. is determined by noting that during the file transfer interval the full capacity of 

1 t 

the link is utilized (Uj = 1.0) and a relatively fixed amount of time (TFj) is devoted in each 
cycle to the transfer of the file frame(s). 

If U j is the utilization associated with the random (non-file transfer) traffic, 

then Tf'. /TC. = 1 - ul 

i i l 

i.e., the fraction of the cycle time devoted to file transfer is equal to the fraction of the 
capacity not used for random traffic. 

Thus: 


TC. = TFl /(I - Uj) 


! 


Uj = (CGTj - GFTj)/Cj 

where GFTj = gross throughput requirement for file transfers on link 
(averaged over the peak hour). 

and CGTj and Cj are the gross throughput and capacity for link i, as discussed earlier. 


i 
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Combining the above expressions: 


TQj = .75 x TFj x Cj/(C. + GFTj - CGTj) 

For the message traffic considered in this study, two "file transfer" queues would 
exist, one for the scheduled FSAS files and the other for the long (30,000 character) AFC 
reports. Table A-13 summarizes the throughput on each NADIN link associated with such 
transfers (from Tables A-6 and A-8). The totals shown in that table are the values for GFT. 

i * 

in the above expression for Uj. 

Since GFT. = 0 for most concentrator-to-switch links, queueing delay for those links 
would be determined as described in A.4.1 above. Although the Jacksonville concentrator to 
Atlanta switch link does involve file (large report) transfers, it is unlikely that a discipline 
such as described above could be implemented at the concentrators. Thus the procedures of 
A.4.1 would also be applicable to that link. 

For the switch-to-concentrator links, both file transfer queues may contain frames 
simultaneously. Thus: 

t 

TFj = 2 x TF. = .44 seconds 

where TF. = the full frame transmission time (.22 seconds), discussed 

earlier. 

and TQ. = .75 x .44 x 9,600/(9,600 + GFTj - CGTj) 

= 3,168./(9,600 + GFTj - CGTj) seconds. 

t 

Determining TFj for the switch-to-switch links is not as direct. Since there are two 
9,600 b/s channels, a randomly arriving message can be transmitted over the second channel 
while a file frame is being transmitted on the first. It is convenient therefore to treat this 
case as if there were a single 19,200 b/s channel; i.e.: 

C. = 19,200 

l 

TFj = m x 260 x 8/19,200 = m x .11 


where m 


the number of file queues used. 




























Thus, for the Atlanta to Salt Lake City fink; 


TQ. = .75 x .22 x 19,200/(19,200 + GFTj - CGTj) 

= 3168/(19,200 + GFT. - CGTj) seconds. 

For the Salt Lake City to Atlanta link: 

TQj = .75 x .11 x 19,200/(19,200 + GFTj - CGTj) 

= 1584/(19,200 + GFT. - CGT.) seconds 

A.4.3 Network Delay Summary 

The above expressions have been used to determine the queueing delays for each 
NAD1N backbone link, considering both the 1983 and 1988 throughput requirements. The 
1988 requirements have been approximated as 122 percent of those for 1983. The results of 
these calculations are shown in Table A-14. 

The queueing delays shown in Table A-14 have been used to calculate the network 
delays (TD), as discussed earlier. Thus, for example, NAS-NAS messages transmitted from 
Jacksonville to Houston will encounter (in 1988): 


Node Processing Delays (4 nodes) = 

4 x .05 

= .20 seconds 

Transmission Delays (3 links) = 

3 x .09 

= .27 

Queueing Delays (3 links): 

ZJX to XTL 


= .45 

XTL to XLC 


= .25 

XLC to XHU 


= .55 

Total Delay 


= 1.72 seconds 
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Table A-15 presents some of the results obtained. Specifically that table lists the nine 
origin/destination pairs which would experience the greatest network delays (as projected 
for 1988). Review of the detailed results indicates: 

• Based on the 1983 throughput estimates, 34 of the 90 NAS-NAS connections 
(i.e., 38 percent) would experience average peak period network delays in excess 
of 1 second. 

• Based on the 1988 throughput estimates, 57 of the 90 NAS-NAS connections 
(i.e., 63 percent) would experience average peak period network delays in excess 
of 1 second. 

• The shortest average delay was found to occur for traffic from Salt Lake City to 
Seattle - .84 seconds for 1983, .90 seconds for 1988. 

A.5 NADIN IA MODIFICATIONS 

The above analysis demonstrates that NADIN, as configured under the Level IA 
configuration, cannot meet NAS-NAS delay constraints without some modifications. Several 
techniques are available for reducing the expected delays. These include: 

• Using a separate dedicated channel on each link for the transmission of large 
files and reports; 

• Modification of the NADIN priority scheme, and hence the network software, to 
assign NAS-NAS messages a higher priority than other ATC messages and/or to 
assign large files and reports a lower priority; 

• Increasing the capacities of selected links, by adding one or more 9,600 b/s 
channels to be used for all message traffic. 
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The first of the above techniques would be the most expensive since it involves some 
software modification and the most added channels. The second would be the least 
expensive since it involves only software modifications. Care must be taken with that 
approach to insure that no ATC messages or files are unduly delayed. 

For purposes of estimating the cost of Alternative 2, the third technique, increasing 
the capacities of selected links, has been assumed. This approach is the simplest to 
implement and provides the basis for a reasonably conservative cost estimate. From an 
analysis of the detailed delay data, it has been determined that the NAS-NAS delay 
constraint can be met for all NAS-NAS origin/destination pairs by adding one 9,600 b/s 
channel to fifteen switch-to-concentrator links. These specifically include: 

• The 10 links between the Atlanta switch and all associated concentrators except 
the one at Boston, and 

• The 5 links between the Salt Lake City switch and the concentrators at Houston, 
Kansas City, Denver, Fort Worth and Salt Lake City. 
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NADIN ENHANCEMENTS TO ACCOMMODATE PACKET SWITCHING 


B.l INTRODUCTION 


B.1.1 Purpose 

This appendix describes a potential enhancement to the National Airspace Data 
Interchange Network (NADIN) based on the implementation of a distributed architecture and 
the employment of state-of-the-art packet-switching technology. The application of such 
technology is addressed only in terms of an evolutionary first step, tailored to facilitating 
the incorporation of Computer B (NAS-NAS) message traffic into NADIN. 

B.l.2 Background 

The trend in communications support for large, dispersed, computer-based systems is 
toward the use of highly connected, distributed networks employing packet-switching 
technology. Such a network appears particularly suitable for meeting the long range 
requirements for Air Traffic Control (ATC) data communications. NADIN, although being 
implemented essentially as a centralized, message-switching network, has an architecture 
that can evolve into such a packet-switched network. 

At the time NADIN was initially designed, packet-switching technology had not 
reached a state-of-the-art consistent with ATC low-risk requirements. Significant progress 
in packet-switching technology and applications over the past several years now makes such 
an approach a viable option for current FAA developments. In fact, the potential for 
increased capabilities at reduced costs provided by such an approach make packet switching 
a particularly attractive option in the present environment of tighter budgets and increasing 
demands on the ATC system. 

The current study, analyzing communications support alternatives for the Computer B 
(NAS-NAS) message traffic, provides a first analytic look at the application of a distributed, 
packet-switched network (DPSN) for ATC communications. This analysis is not a full-scale 
evaluation of DPSN for all present and future ATC applications. Rather: 




• it considers the introduction of packet switching as an enhancement to the 
NADIN architecture; 

• it only considers use of the network for that message traffic to be included under 
the Level IA implementation of NADIN plus the NAS-NAS message traffic; 

• it does not address the detailed architectural changes to best support other ATC 
requirements; and 

• it does not address the network transition approach. 

Nevertheless, the analysis (see Appendix C) demonstrates the cost-effectiveness of 
employing a DPSN for ATC applications. 

B.1.3 Outline 

The enhancements to the NADIN architecture, envisioned for the initial implementa¬ 
tion of the DPSN concept, are presented in the next three sections. Specifically: 

• Section B.2 presents a general overview of the DPSN concept. 

• Section B.3 describes the NADIN IA architecture, as a basis for discussing 
enhancements. 

• Section B.4 discusses the enhancements directly. 

The final section, Section B.5, discusses other capabilities and enhancements that might be 
of interest for longer range considerations. 

13.2 CONCEPT OVERVIEW 



General references to packet-switching technology usually presume the integration of 
four architectural elements: 
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• packet switching; 


• multiplexing; 

• high connectivity; and 

• distributed control. 


Although each of these elements can be implemented independently, the manner in which 
they complement each other has made their combination a very desirable approach for 
large, computer-based data communications network designs. The DPSN addressed by this 
memorandum specifically includes all four elements. 

The general implications of these design elements are discussed below. Their specific 
application for the enhancement of NADIN is presented in subsequent sections. A more 
complete discussion of these concepts can be found in Reference 18. 


Packet Switching 


Packet switching is a method of operating a telecommunications network in which 
short message units, called packets, are handled independently by the backbone network. A 
limit on the size of a packet is defined for the network; each message entering the network 
is therefore converted into one or more packets, depending on its size. In its simplest form, 
packet switching involves the buffering and forwarding of the individual packets by 
successive network nodes along the transmission path. This basic concept is also reflected 
in the link level ADCCP protocol used on the NADIN IA backbone links. In NADIN IA, 
messages are transmitted in units called frames, each containing a maximum of 245 message 
characters. 

The major advantage of packet switching is that it facilitates the network's handling 
of traffic from diverse data terminals and computers operating at different speeds. A 
broader spectrum of advantages can be obtained by combining packet switching with 
multiplexing, high connectivity and distributed control. 

Packet switching can be implemented in two basic ways - datagram service and virtual 
circuit service. Virtual circuit service, in turn, can be implemented in a number of ways. 
The X.25 standard protocol recommendation (Reference 19) supports all such variations. 
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With datagram service, each packet is handled independently by the network. At each 
node that receives the packet, only the next link on the packet's journey to its destination is 
determined. If messages are divided into two or more packets, it is possible for successive 
packets to be directed along different routes and to arrive at the destination out of 
sequence. Resolution of packet sequence must then be performed by the receiving 
individual, intelligent terminal or computer. 

The major advantages of datagram service are that it requires no end-to-end circuit 
set up and it provides for more balanced use of network link capacities. Its disadvantages 
are the relatively high overhead in network control messages that provide the nodes the data 
on which to select the best next link, and the need for user sequencing of received packets. 

Virtual circuit service overcomes the packet sequencing problem of datagram service 
by including mechanisms for packet sequencing within the network itself. Two of the more 
efficient techniques that have been used to accomplish this are: 

• buffering and sorting of a limited number of packets from a single message at 
the last backbone node to handle the message; and 

• establishing a fixed path over which all packets from a single message will flow 
in sequence. 

The former approach is very similar to datagram service in terms of the handling of 
individual packets. It does, however, require additional network resources for buffering and 
sequencing, and results in added network delays. The latter approach sacrifices the 
assurance of balanced link usage and so may result in greater delays due to link congestion. 
Establishment of a fixed path, however, can reduce node processing delays, especially for 
longer messages and sequences of messages between two network users. 

Either of the above approaches to packet sequencing can be used with either of the 
two major variations of virtual circuit service - virtual call and permanent virtual circuit. 
With virtual call service, a virtual circuit is established for the duration of a specific "call," 
possibly including responses to the call. With permanent virtual circuit service, the virtual 
circuit is established for an indefinite period. Both variations require added network 
overhead in order to set up and break down the virtual circuits. With permanent virtual 
circuits, this is done much less frequently; however, this means that buffers and other 
network resources will be tied up even when not in use. 
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As indicated above, each of the various approaches to packet switching has advantages 
and disadvantages. The optimal approach must be determined through analysis of message 
traffic characteristics, delay constraints and available resources. 

B.2.2 Multiplexing 

Packet switching would offer few benefits without multiplexing. Multiplexing refers 
to the use of one high speed (capacity) communications channel to handle (essentially 
simultaneously) messages received from a number of lower speed channels. Standard 
techniques include time-division multiplexing (TDM) and frequency-division multiplexing 
(FDM), whereby each incoming channel is assigned a specific portion of the outgoing 
channel's resources (transmission time cycle for TDM, frequency bandwidth for FDM). 

For packet switching a variation of TDM called statistical multiplexing (or concentra¬ 
tion) is generally used. Only one packet is transmitted over a backbone channel at a time; 
however, there are no fixed time slots. Rather, packets are interleaved, generally in the 
order they are received or generated (barring special priority considerations). This allows 
use of an output channel which has less capacity than the sum of the capacities of the input 
channels. Level IA NADIN uses this technique in the transmission of ADCCP frames 
between concentrators and switches. 

B.2.3 Connectivity 

A network is considered highly connected if it would take an unusually large number of 
simultaneous link outages to eliminate all communications paths between any two nodes. 
This is achieved through a network topology that includes direct links from each node to two 
or more other nodes. 

NADIN under the Level IA configuration does not provide high connectivity. Rather, 
it relies on a dial back-up service in the event of link outages. The current NAS-NAS 
network does have a highly connected topology; however, it does not provide the mechanism 
for switching the messages along an alternate route. Rather, the NAS-NAS network uses 
redundant lines between pairs of ARTCCs to provide back-up service in the event of line 
outages. 

In addition to its value in the event of line outages, high connectivity can also provide 
alternate routing capability to avoid primary paths that are congested. This routing 
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capability is generally used to optimize loading in packet-switched networks. Optimally, 
each packet could be independently routed over the path that instantaneously has the 
minimal end-to-end delay. Alternatively, a minimal delay path could be temporarily 
established for transmission of a series of packets between a given pair of nodes. 

B.2.4 Distributed Control 

Level IA NADIN involves centralized routing control, in that most messages are 
directed to one of the two switches for processing and routing. The exceptions are the 
locally switched (e.g., FDIO) messages which do not use the backbone links. 

Completely centralized routing control for highly connected networks becomes some¬ 
what inefficient. Generally, for such networks, switches are located at many (or all) 
backbone nodes and the routing control is distributed among those switches. Some 
centralized control is usually retained to coordinate the functioning of the otherwise 
independent switches. 

Distributed control is made possible by the sharing of link status and utilization data. 
Pertinent data (e.g., packet queueing delays) are continuously collected and made available 
to each switching node. The nodes use these data in conjunction with a routing algorithm to 
update routing tables. The network overhead implied by the collection, distribution and/or 
accessing such data is relatively large. This is generally compensated for, however, by the 
increased efficiency of the resulting routes. 

B.3 NADIN IA ARCHITECTURE 

The enhancements to the NADIN architecture being considered to implement packet 
switching represent a minimum of changes - just those needed for the efficient support of 
NAS-NAS and Level IA NADIN message traffic. Understanding of the enhanced archi¬ 
tecture is thus facilitated by first reviewing the Level IA architecture and then identifying 
the changes to that architecture. 

NADIN is currently being developed as a centralized network. It includes two 
interconnected, centrally located, message-switch nodes. These are each connected by a 
star-patterned subnetwork to eleven or twelve concentrator nodes. Under the Level IA 
implementation the link between a switch and each associated concentrator consists of one 
full-duplex, voice-grade line, operating at 9,600 bits per second (b/s). The link between the 
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two switches consists of two such lines. The two switches, the twenty-three concentrators 
and the links interconnecting them make up the NADIN backbone network. The complete 
network can be considered to also include the various ATC data terminals and computers 
which use the NADIN facilities and the circuits and subnetworks by which they are linked to 
the backbone network. 

Typically, a NADIN message is directed from the originating data terminal or 
computer through a concentrator to the associated switch. The switch then routes the 
message to its destination (terminal or computer) by way of the other switch, if necessary, 
and the concentrator to which the destination is linked. Variations to this typical routing 
include local switching at the concentrators for certain message traffic and the entry/exit 
at the switches for message traffic involving external systems (e.g., WMSC and International 
AFTN). 

The NADIN concentrators are intelligent statistical multiplexors. Their major 

functions include: 

• limited message processing, e.g., code and format conversion; 

• local switching of pertinent traffic, including the collection and periodic 

forwarding of statistics on such traffic to the central switch; 

• application of link-level protocols, including the fragmenting/reassembly of 
messages into/from ADCCP frames; 

• buffering of messages; and 

• multiplexing/demultiplexing of message frames. 

Each switch consists of two major components - a front-end processor (FEP) and a 
message processor (DS714). The FEP is functionally and physically similar to a NADIN 
concentrator. It performs the actual switching functions. All links to the NADIN switch are 
through the FEP. The DS714 is a computer with associated peripheral equipment (e.g., tape 
and disk drives). Its functions include: 
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message editing; 




• message routing; 

• message recording/recovery; 

• accounting; and 

• network control. 

B.4 ENHANCED ARCHITECTURE 


Many of the NADIN IA architectural elements are consistent (or at least not 
inconsistent) with requirements for a DPSN capable of also supporting NAS-NAS message 
traffic. In the first evolutionary step to implement packet switching, such elements should 
be retained. As a result, the major modifications required are: 

• increased backbone node connectivity; 

• addition of the packet-switching function; and 

• modification or relocation of some network functions, as necessitated by the 
implementation of packet switching (e.g., the routing function). 

The enhanced architecture is described in the following subsections in terms of: 

• retained NADIN IA elements; 

• connectivity; 

• backbone nodes; and 

• routing/switching functions. 
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B.4.1 Retained NADIN IA Elements 


Neither the application of packet switching nor the incorporation of NAS-NAS traffic 
suggests any reason for relocating the NADIN backbone nodes. On the contrary, since the 
NADIN concentrators are to be collocated and interfaced with the NAS 9020s, the 
concentrator node locations are optimal for NAS-NAS support. 

The requirement to provide some processing and concentration at the concentrator 
nodes will continue to exist under the enhanced architecture. In order to accommodate 
additional DPSN functions at those nodes, any one of three options could be implemented. 
These are: 

• enhancement of the concentrators to perform the new functions (including 
packet switching); 

• replacement of the concentrator by a new combination concentrator/packet- 
switch unit; or 

• addition of a separate packet-switch module (PSM), retaining the concentrators 
and enhancing them only to the degree needed to appropriately interface with 
the PSMs. 

The latter of the above options is suggested for the initial implementation of packet 
switching, since that approach would have minimal impact on the system currently being 
implemented. This approach has been assumed in the more detailed analyses in this study. 

Although not pertinent for NAS-NAS traffic, many NADIN messages would continue to 
require the message processing functions provided by the DS714 and best provided at 
centralized locations. These would include primarily those messages which must be 
recorded for possible retrieval, those to or from external systems and those to or from less 
intelligent terminals, which require editing and routing support. Thus the DS714 message 
processors would be retained under the enhanced architecture. Similarly, the FEPs would be 
retained to serve as the front ends for the DS714s and as the gateways for external systems. 

As implied by the above discussion, there would be no need to change the interfaces 
between the concentrators and the various data terminals and computers that use NADIN, 
nor between the FEPs and the external systems. Further, there would be no need to modify 
the basic NADIN message format. 


B-9 




B.4.2 Connectivity 


Consideration of the conversion of NADIN into a DPSN was motivated by the 
NAS-NAS requirements for shorter network delays and better back-up service than would be 
available under the NADIN IA architecture. Higher connectivity for the NADIN nodes would 
be a major step in meeting both of those requirements. Provision of direct links between 
concentrators at many adjacent ARTCCs would reduce network (node) processing for most 
NAS-NAS messages. The availability of alternate routes would reduce possible congestion, 
thus reducing delays on individual links and, further, would provide back-up service of 
almost equivalent quality to the primary service, should a primary route link be out. 

In order to estimate the cost of the DPSN approach, a minimal-connectivity DPSN 
topology has been determined (see Appendix C). The criteria used in determining that 
network included the following: 

• All links would consist of one or more 9,600 b/s channels. 

• At least two non-overlapping paths would exist between each pair of packet- 
switch nodes. 

• The average network delay for all NADIN traffic would be less than two seconds 
during a busy hour. 

• The average network delay for NAS-NAS messages between any pertinent pair of 
origin/destination nodes would be less than one second during a busy hour. 

• Network costs would be minimized. 

The optimal network topology determined consists of 31 links made up of 37 channels 
operating at 9,600 b/s. Nine of these channels are identical with ones included under the 
Level IA implementation. The monthly communications cost for this configuration, using 
the 1981 MPL tariffs, would be approximately $4,500 more than for the NADIN IA 
configuration. This compares with a cost of approximately $50,000 per month for the 
current NAS-NAS network. 
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B.4.3 Backbone Nodes 


As suggested earlier, the NADIN 1A backbone nodes would be retained under the 
enhanced architecture. The composition and function of the nodes would be changed, 
however; e.g., PSMs would be added. Under the NADIN IA architecture, there are two types 
of nodes: 

• message-switch nodes at the Atlanta and Salt Lake City ARTCCs, which also 
include concentrators; and 

• concentrator nodes at the 18 other CONUS ARTCCs and at three off-shore 
ARTCCs (Anchorage, Honolulu and San Juan). 

The enhanced NADIN architecture would result in three types of nodes: 

• combined message-switch, packet-switch nodes at the Atlanta and Salt Lake 
City ARTCCs, which would also include concentrators; 

• packet-switch nodes at the 18 other CONUS ARTCCs, which would also include 
concentrators; and 

• concentrator nodes at the three off-shore ARTCCs. 

The three off-shore nodes would remain essentially unchanged for this initial DPSN 
application. This is practical since they would not be origins or destinations for any 
NAS-NAS traffic, it would be unlikely that they would be selected as part of alternate 
routes for messages between other nodes, and they are not expected to generate much 
NADIN backbone traffic. Each of the off-shore concentrators would be linked directly to 
the PSM at a convenient packet-switch node. Those concentrators would thus be 
functionally modified in the same manner as the other 20 concentrators. 

The modifications to the two message-switch nodes are indicated in Figure B-l. The 
major change is seen to be the addition of the PSM and the transfer of the major switching 
function from the FEP to the PSM. The FEP would continue to serve as the front end for 
the DS714 and as a gateway for external systems. The concentrator would continue to serve 
as the backbone network access point for ATC data terminals and computers. 
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B.4.4.2 Function Separation 

Many of the individual functions associated with routing could be performed by either 
the PSM or concentrator/FEP. As a general consideration, the PSM should be assigned 
nearly all major new functions, i.e., those not included under Level IA NADIN. This would 
minimize needed modifications to the concentrators and FEPs. However, the 
concentrators/FEPs would be responsible for functions such as message packetizing and 
message traffic accounting, although these functions would be somewhat changed from 
similar functions performed under Level IA NADIN. Further, the DS714 would perform the 
centralized routing control function, including the establishment and adjustment of 
permanent virtual circuits (if used). 

All functions associated directly with packet switching would be assigned to the PSM. 
These would include the buffering of received messages, the determination of the 
appropriate next link, the maintenance of routing tables and the implementation of packet- 
level (level 3) protocols. Additional study would be required to determine the optimal 
location of functions such as the establishment of virtual calls and the association of service 
type to message class. 

B.5 OTHER POSSIBLE ENHANCEMENTS 


The enhanced NADIN architecture discussed above represents a first, minimal 
evolutionary step directed to the accommodation of NAS-NAS message traffic by a DPSN 
version of NADIN. In order to better accommodate other types of traffic, especially those 
that might be added to NADIN in the future, there are a number of other enhancements that 
might be considered. These include: 

• consolidation of PSM and concentrator/FEP functions into a single hardware 
unit; 

• conversion of the three off-shore nodes into packet-switch nodes; 

• further increasing network connectivity; and 


addition of concentrator nodes. 





The latter, which is the only one of the four not alluded to earlier, would involve the 
location of NADIN concentrators near clusters of ATC data terminals, e.g., major airports. 
Such concentrators could be linked directly to the PSM at the associated ARTCC. This 
would significantly reduce the load on the center concentrators and would most likely 
reduce the communications cost associated with local access to the backbone network. It is 
anticipated thus such an architectural extention will be analyzed as part of Task 3 under this 
contract. 
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NETWORK DESIGN FOR ALTERNATIVE 3 


C.l PURPOSE AND SCOPE 


This appendix describes the analysis performed to develop an enhanced NADIN 
architecture capable of satisfying the 1988 performance requirements of the NADIN 
Level IA traffic and the NAS-NAS traffic. It presents the data and assumptions used in the 
analysis, and outlines the methodology employed. 

C.2 GENERAL APPROACH 


Under Alternative 3, the NADIN architecture would be enhanced to provide distributed 
packet switching. Such a distributed architecture should, in comparison with NADIN IA, 
result in greater reliability and reduced delays achievable for a given cost. Such an 
architecture could also serve as an interim step in the expected evolution of NADIN >nto a 
packet-switched network serving all ATC message traffic. 

In determining the optimal architecture of this type, the following assumptions have 
been used: 


1. The backbone network nodes would be located at the 20 CONUS ARTCCs (and, 
probably, the 3 overseas ARTCCs). 

2. The 20 CONUS nodes would all be packet switches with limited message 
processing capabilities. 

3. Special message processing functions (performed at the two switches under the 
NADIN I and IA implementations) would be performed under Alternative 3 by 
message processors (switches) collocated with the Atlanta and Salt Lake City 
packet switches. These functions would include message recording for historical 
purposes and routing assistance for messages from external systems and less 
sophisticated terminals. 
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These processors would be considered as network hosts, rather than network 
communications nodes. 

4. As under NADIN I and IA, the 20 CONUS nodes would be divided into two groups 
- 11 in the East group and 9 in the West. Messages requiring special processing 
that originate at one of the East switches would be routed to the Atlanta 
processor; those that originate at one of the West switches would be routed to 
the Salt Lake City processor. 

5. Network links would consist of one or more full duplex, voice grade lines, 
operating at 9,600 b/s. 

6. Node interconnections would be such that at least two non-overlapping routes 
exist between every pair of nodes. 

7. The backbone links for this network would be used to transmit the same 
categories of traffic as specified for Alternative 2 (see Appendix A); i.e., 
NADIN I, AFC, NFAS, NFDC/IS and NAS-NAS. 

This analysis has addressed only a generalized concept of a distributed architecture. 
As a result, it has not addressed: 

• possible relocation of backbone network nodes, 

• changes required to the network protocol, and 

• possible changes in message priority handling. 

The optimal set of links for the backbone network has been determined with the aid of 
GRINDER, a NAC proprietary package of interactive network design programs. The 
specific programs employed were those that determined costs, link flows (throughput 
routing) and end-to-end delays for specific network configurations, and that suggested 
configuration changes to meet end-to-end delay constraints. These applications required the 
following inputs: 





network node locations, 


• throughput requirements for each origin/destination pair, 

• tariffs for the pertinent communications service, 

• various parameters for delay calculations, e.g., frame length, node processing 
time and overhead factors, and 

• the delay constraint. 

The special considerations associated with these inputs are discussed below. 

C.3 INPUT CONSIDERATIONS 


The GRINDER generalized network representation includes several features that do 
not directly reflect the Alternative 3 concept. These limitations and their resolutions are 
outlined below with reference to the major input categories. 

C.3.1 Network Nodes 


GRINDER generally requires the identification and location of all terminals and host 
computers, and the actual or potential location of communications facilities (backbone 
nodes). For the specific GRINDER programs used, however, it was not necessary to include 
the terminals end hosts. Rather it was sufficient to identify the origins and destinations of 
message traffic as the backbone nodes at which messages enter or leave the network, 
respectively. Further it was assumed that the backbone nodes would be located at the 
20 CONUS ARTCCs. 

C.3.2 Throughput Requirements 

Throughput requirements are input to GRINDER separately for each origin/destination 
pair. It was thus necessary to translate the link-associated throughput specified in 
Appendix A into the required format. The results of that effort are presented in Section C.4 
below. 
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The throughput translation process encountered two major areas of difficulty. First, 
direct specification of end-to-end throughput would not insure that pertinent messages 
would be routed through the message processors. Second, there would be no way of 
reflecting the file transfer considerations discussed in Appendix A. The former problem was 
resolved by treating each message to be routed through a message processor as two 
messages - one from the origin node to the associated processor node, the other from the 
processor node to the destination node. This approach affected the specification of the end- 
to-end delay constraint, discussed later. 

The file transfer considerations outlined in Appendix A could not be reflected with 
GRINDER. Rather, the conservative file transfer throughput estimates were treated as 
representing random traffic. This approach results in delay estimates that are low on links 
with low utilization and high on links with high utilization. The existence of alternate 
routes in the network would tend to make file transfers appear more random and thus 
minimize any errors this approach might introduce. 

C.3.3 Tariffs 

TELPAK tariffs, currently applicable for government leased lines, are scheduled to be 
discontinued. Thus in determining the relative costs of various configurations, the MPL 
tariffs were used. These are discussed in Appendix D. It was further assumed that all 
backbone nodes were located in areas designated "Category A" under MPL tariffs. 

C.3.4 Delay Parameters 

Delays are calculated by GRINDER in essentially the same manner as discussed for 
random traffic in Appendix A. GRINDER, however, includes the node processing delay only 
once for each link. Thus GRINDER'S calculation of end-to-end delay will always differ from 
that calculated as in Appendix A, by the delay associated with one node (.05 seconds). This 
discrepancy was easily resolved, as discussed below under Delay Constraint. 

GRINDER provides for the input of net throughput requirements and multiplicative 
link and network overhead factors. It was convenient, however, to input the gross 
throughput values, which reflect multiplicative and non-multiplicative overhead factors, and 
to specify the overhead factors as zero. This approach assured greater consistency between 
the analyses for the separate alternatives. 
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C.3.5 Delay Constraint 

GRINDER accepts as input a single end-to-end (network) delay constraint; i.e., the 
maximum acceptable value of end-to-end delay for the average frame. Starting from any 
network configuration, it will attempt to find the least-cost configuration meeting that 
constraint by adding, deleting and changing the multiplicity of specific links. 

NADIN IA specifications require an average peak-period delay of two seconds or less. 
The NAS-NAS traffic requirement is more severe; the average delay for such messages must 
be no greater than one second. Further, this latter constraint is assumed to apply to each 
NAS-NAS origin/destination pair, rather than to the average NAS-NAS traffic nationwide. 
The selection of the appropriate delay constraint was also affected by the need to treat 
some (non-NAS-NAS) messages as two messages within GRINDER and the bias of .05 
seconds in the GRINDER calculations, as discussed earlier. 

In order to reflect all of these considerations, a two phased application of GRINDER 
was employed. In the first phase a distributed network paralleling the NAS-NAS network 
was input, and a 1-second end-to-end delay constraint was specified. GRINDER produced an 
"optimal" modified network with an average end-to-end delay of approximately 1 second 
(2 seconds for messages routed through the processors). Since the delay constraint applied 
to average message frames, about half of the traffic, including some NAS-NAS traffic, had 
GRINDER-calculated delays greater than 1 second. 

In the second phase, judgement was used to modify the GRINDER-generated config¬ 
uration, through the addition of links, the increasing of existing link capacities and the 
deletion of links (to keep down costs). At each step in this trial-and-error process, 
GRINDER was employed to calculate the costs and delays for the modified design. This 
process was continued until a design was achieved which: 

• yielded a GRINDER-calculated average end-to-end delay of less than .95 
seconds, 

• yielded no GRINDER-calculated delay between any NAS-NAS origin/destination 
pairs greater than .95 seconds, 

• provided at least two non-overlapping routes between each pair of backbone 
nodes, and 
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• could not be further modified to significantly reduce costs without violating one 
of the above conditions. 

C.4 THROUGHPUT REQUIREMENTS 

The throughput requirements associated with Alternative 3, although stated in 
different terms, are essentially the same as those for Alternative 2. The only major 
difference results from the consolidation of the two nodes (switch and concentrator) at 
Atlanta and at Salt Lake City into single nodes. Thus some traffic, e.g., transmissions 
between the Atlanta AWP and FSDPS, would no longer appear on backbone links and would 
thus be ignored. 

The 1983 requirements, stated as peak-period throughput for each origin/destination 
node pair are presented below, separately for each traffic category and collectively over the 
five categories. All values shown were increased by 22 percent to reflect the 1988 
requirements. The special considerations and assumptions involved in translating the data in 
Appendix A are also presented. 

C.4.1 NADIN I Traffic 


It has been assumed that all NADIN I traffic will be routed through the message 
processor associated with the origin node. Thus most such messages will be counted twice, 
once for transmission from the origin switch to the processor switch and once from the 
processor switch to the destination switch. If the processor switch is also the origin or 
destin r switch, no backbone links would be used for one (or both) of the two 
transmissions. Only transmissions using the backbone links are considered. 

In translating the NADIN I link traffic presented in Appendix A, the following 
additional assumption have been used: 

1. Of the traffic previously designated as "concentrator-to-switch," 73 percent is to 
be routed back to the originating concentrator or to other concentrators. The 
remaining 27 percent is destined for terminals, computers or external systems 
connected to the switch. This breakout is consistent with the NADIN I design 
data. 
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Of the 73 percent that is to be retransmitted over the backbone network, an 
equal amount of traffic (collectively from all concentrators) is to be forwarded 
to each of the 20 concentrators. 


3. Any of the previously designated "switch-to-concentrator" traffic not accounted 
for above (i.e., not originating at one of the concentrators) is assumed to 
originate at a terminal, computer or external system connected to the switch. 

4. All of the previously designated "switeh-to-switch" traffic is to be routed to a 
concentrator associated with the receiving switch (as opposed to being destined 
for a terminal, computer or external system connected to that switch). 

The results of applying the above assumptions to the data in Table A-l (Appendix A) 
are shown in Table C-l. Here, and in subsequent tables and figures of this appendix, the 20 
Alternative 3 nodes are designated by the symbols used previously to designate Alternative 2 
concentrators (see Table A-3, Appendix A). Thus, for example, ZTL designates the Atlanta 
switch under Alternative 3. 

C.4.2 AFC Traffic 

Under Alternative 3 it has been assumed that no AFC traffic would be routed through 
the message processors. Rather all flight data will be destined for the Jacksonville switch 
and all flow control messages will originate at or be destined for the Jacksonville switch. 
This specifically implies that all message duplication must be accomplished before messages 
leave Jacksonville. 

The translation of the throughput requirements under Alternative 2 (Tables A-4 and 
A-6, Appendix A) to requirements under Alternative 3 is relatively direct, requiring 
consideration only of the traffic originating or terminating at the 19 nodes other than 
Jacksonville. The results of this translation are shown in Table C-2, for Flight Data 
Messages, and Table C-3, for Flow Control Messages. 

C.4.3 FSAS Traffic 

Each of the three FSAS message categories, identified in Appendix A, involved distinct 
considerations in translating the throughput requirements. These are summarized below: 
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MESSAGE CHARACTERISTICS PEAK THROUGHPUT (B/S) 
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C.4.3.1 File Transfers 

All file transfers originate at the AWPs, which are collocated with the processor nodes 
(Atlanta and Salt Lake City). Thus the previous "switch-to-concentrator" file traffic will 
originate at the processor nodes and be destined for the other, associated (East or West) 
switches. The previous "switch-to-switch" file traffic involves only AWP-to-AWP transfers; 
thus such traffic involves the two processor nodes as origins and destinations under 
Alternative 3. 

C.4.3.2 ARO Messages 

All ARO messages originate or terminate at Jacksonville. It is assumed that these will 
not be routed through the message processors. Thus, as with the AFC traffic, translation of 
such traffic requires only the consideration of ARO traffic originating or terminating at the 
other 19 nodes. 

C.4.3.3 Other Messages 

All other FSAS messages are assumed to be routed through the message processors. 
Most of these remain in the same region (East or West) as the originating node. The 
Alternative 2 "concentrator-to-switch" and "switch-to-concentrator" traffic directly 
identifies the origin/destination traffic for such messages. 

Some of these messages are, however, exchanged between East and West nodes. These 
are included in the twenty-four 60-character messages per hour and 24 (of the 459) 15- 
character messages per hour transmitted from each FSDPS (located at the ARTCC) to the 
19 other FSDPSs (located at the 19 other ARTCCs). It is assumed that the destinations for 
such messages are equally distributed over the 19 other nodes. Thus there will be 
(11 x 24) 264 messages of each of the two types transmitted to the Atlanta message 
processor. Of these, (10/19) 53 percent will be retransmitted to East nodes and (9/19) 47 
percent to West nodes. Thus each of the eleven East nodes will receive (.53/11) 4.8 percent, 
and each of the nine West nodes will receive (.47/9) 5.3 percent. Similarly, of the 
(9 x 24) 216 messages of each of the two types transmitted to the Salt Lake City processor, 
(8/19) 42 percent will be retransmitted to West nodes and (11/19) 58 percent to East nodes, 
with (.42/9) 4.7 percent going to each West node and (.58/11) 5.3 percent to each East node. 
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In translating the link traffic into origin/destination traffic, it was thus necessary to 
subtract from the Alternative 2 "switch-to-concentrator" traffic those messages originating 
in the other section of the U.S. For example, the "other" traffic from the East processor 
(ZTL) to any other East node would be the "switch-to-concentrator" traffic for 
Alternative 2, reduced by the cross-country messages; i.e., (216 x .053) 11.4 less messages 
per hour of each the 60- and 15-character messages. These cross-country messages would 
now originate at the West processor (ZLC). 

C.4.3.4 Summary of FSAS Traffic 

Table C-4 presents the results of translating the Alternative 2 FSAS throughput 
requirements (Table A-8, Appendix A) to origin/destination format. As with previously 
discussed traffic categories, messages not transmitted over backbone links are ignored. 

C.4.4 NFDC/IS Traffic 


All NFDC/IS traffic considered involves transmission between Washington and Atlanta 
or between Atlanta and Salt Lake City. Thus the Alternative 2 requirements (Table A-9, 
Appendix A) translate directly into Alternative 3 requirements. These are presented in 
Table C-5. 

C.4.5 NAS-NAS Traffic 

NAS-NAS throughput requirements were previously developed in an origin/destination 
format. Since such messages need not be routed through the processor nodes, the original 
data have been directly applied for Alternative 3 analysis. These are presented in 
Table C-6. 

C.4.6 Total Throughput Requirements 

The requirements identified above have been accumulated for each pertinent 
origin/destination pair in Tables C-7 and C-8. Table C-7 presents all traffic with origin or 
destination at one of the three busiest nodes - Atlanta, Salt Lake City and Jacksonville. 
This includes all of the requirements except some of the NAS-NAS traffic. The remaining 
requirements are presented in Table C-8. 
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TABLE C-8: CUMULATIVE PEAK PERIOD MESSAGE TRAFFIC FOR 
OTHER ORIGIN/DESTINATION PAIRS 
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C.5 OPTIMAL CONFIGURATION 


The optimal configuration determined for the Alternative 3 network concept is shown 
in Figure C-l. This configuration interconnects the 20 nodes with 31 links, six requiring two 
9,600 b/s lines, the remainder requiring single 9,600 b/s lines. 

The optimized routing of all 1988 traffic suggested by GRINDER results in link delays 
(ignoring all node processing delays) shown in Table C-9. The end-to-end delays for all 
90 NAS-NAS origin/destination pairs have been computed. The 16 origin/destination pairs 
with the greatest delays are shown in Table C-10 (including all node processing delays). 
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LINK NODES 


LINK DELAY (SEC.) FROM: 


A 

B 

A to B 



ZOA 

.14 

.11 


ZLC 

.14 

.43 

ZOA 

ZLA 

.12 

. C 

ZLA 

ZLC 

.15 

.77 

ZLA 

ZAB 

.17 

.18 

ZLC 

ZAB 

.85 

.18 

ZLC* 

ZDV* 

.48 

.12 

ZDV 

ZAB 

.16 

.15 

ZOV 

ZMP 

.14 

.11 

ZDV* 

ZKC* 

.19 

.12 

ZAB 

ZFW 

.41 

.24 

ZKC 

ZMP 

.14 

.10 

ZKC 

ZFW 

.15 

.11 

ZMP 

ZAU 

.18 

.24 

ZAU* 

ZIO* 

.11 

.16 

ZKC 

ZME 

.38 

.55 

ZFW 

ZHU 

.27 

.26 

ZHU 

ZME 

.11 

.25 

ZID 

ZOB 

.16 

.12 

ZIO* 

ZTL* 

.11 

.36 

ZME* 

ZTL* 

.12 

.33 

ZHU 

ZMA 

.20 

.17 

ZTL 

ZOB 

.54 

.17 

ZTL 

ZOC 

.61 

.18 

ZTL* 

ZJX* 

.37 

.19 

ZOB 

ZBW 

.22 

.13 

ZOB 

ZOC 

.12 

.11 

ZOC 

ZNY 

.21 

.21 

ZNY 

ZBW 

.15 

.12 

ZJX 

ZNY 

.48 

.13 

ZJX 

ZMA 

.42 

.21 


* Indicates dual - 9,600 b/s links. 


TABLE C-9; ALTERNATIVE 3 LINK DELAYS 
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ORIGIN DESTINATION | END-TO-END DELAY (SEC. 
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APPENDIX D 


COST ANALYSIS METHODOLOGY AND DATA 


D.l PURPOSE AND SCOPE 

This appendix presents the general methodology used to estimate the cost of the 
various alternatives for supporting NAS-NAS communications. The methodology has been 
designed to provide results that can be directly compared, despite the many unique 
considerations pertinent to individual alternatives. This appendix also presents the common 
data (parameter values) used to implement the methodology. 


D.2 COMPARABILITY 

The intent of the methodology is to produce for each alternative a single cost estimate 
that can be directly compared with the cost estimates for all of the other alternatives. In 
analyzing the various alternatives for supporting NAS-NAS communications, achieving 
comparable costs requires careful attention to three areas of complexity: 

1. the aggregation of one-time and recurring costs; 

2. the treatment of costs for systems that currently exist (or would be procured 
regardless of the alternative selected), but would be eliminated by one or more 
of the alternatives; and 

3. the treatment of costs for excess NADIN communications capacity, available 
before or after the incorporation of the NAS-NAS services. 

The manner in which these three areas have been handled essentially defines the cost 
methodology employed. Each is discussed separately below. 



D.2.1 Life-Cycle Costs 

One-time costs refer to expenditures for items such as hardware purchase, software 
development and systems installation. Such items are generally considered to occur and be 
paid for when the system is implemented or modified. If the new or modified system is 
expected to have a long life, some of these items will reoccur; for example, worn-out 
equipment would have to be replaced by newly purchased equipment. 

Recurring costs refer to expenditures for such items as equipment leasing and system 
maintenance. Such items occur on a regular or (frequent) as-needed basis. For cost analysis 
they are considered to be paid for in fixed amounts (ignoring inflation) at regular time 
intervals (e.g., once a month). 

Because of the different time factors involved, one-time and recurring costs cannot be 
directly added. This is generally handled by defining the system's lifetime and then 
including each cost item as often as it is expected to occur over one life-cycle. For this 
analysis a lifetime of 10 years (120 months) is assumed. 

Another important difference between one-time and recurring costs is that a dollar 
spent today effectively costs more than one spent next year (ignoring inflation). This is so 
because a dollar spent today either must be borrowed, implying interest costs, or, if already 
available, cannot be invested, implying lost interest payments. This difference is generally 
resolved by calculating the present value of recurring costs (and of one-time costs that 
occur at a later time). The present value can be thought of as the amount of money that 
would have to be invested at the start in order that the combined principal and interest 
would exactly pay all the future costs, when due, over the life-cycle of the system. Such 
costs could be added directly to the initial one-time costs. 

Standard models exist for estimating present values of future costs. Because of the 
limited lifetime of the systems being considered, all one-time costs are assumed to be 
expended only in 1983 (Subsection D.2.2, below, includes discussion of pre-1983 costs). The 
1983 present value of the recurring costs can be calculated using: 


PV = 

RC x (1- (1+D) " m )/D 

where 


PV = 

the present value, in dollars. 

RC = 

the recurring costs, in dollars per month, 
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m - the system lifetime, in months, 

and D = the effective cost of money, on a monthly basis. 

If inflation is ignored, D would be the monthly interest (or discount) rate. If inflation is to 
be considered, D would be determined as: 

D = 1 - (1+I)/(1+F) 

where 

I = the monthly interest rate, 

and F = the monthly inflation rate. 

For this analysis D is taken to be .008 per month (.10 per year) and m is taken as 120 
months. Thus: 

PV = RC x 77.0 

D.2.2 Existing Systems 

It is assumed for this analysis that, regardless of which alternative for NAS-NAS 
communications support is implemented, the NAS-NAS Network would be operated through 
the beginning of 1983, and that NADIN Level IA would be implemented by 1983. Thus any 
costs associated with those systems prior to 1983 would be the same for all alternatives, and 
thus need not be considered in determining comparative costs. 

The NAS-NAS Network would be retained in some form only under Alternatives 1 
and 4. Thus all costs associated with the continued operation of that network (as modified, 
under Alternatives 4) must be included only in analyzing those two alternatives. 

NADIN, on the other hand, would continue to be operated under all five alternatives, 
including in particular Alternative 1. It is convenient, therefore, to consider the cost of 
continuing to operate the NADIN Level IA implementation as a common cost for all 
alternatives, and thus to (generally) ignore that cost in the analysis. Thus, for example, 
Alternative 2 costs need include only the one-time and recurring costs associated with 
increases in link capacities. This approach cannot, however, be directly applied to 
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Alternative 3, since the network architecture would be significantly modified. In order to 
be consistent, the total cost associated with the Alternative 3 modifications and operation 
must be determined. Then, in order that the cost be comparable to that for the other 
alternatives, it must be reduced by the cost of continuing to operate NADIN under the 
Level IA implementation. 

D.2.3 Excess Capacity 

In order to insure a robust communications system, links are designed with capacities 
in excess of those required. Thus, for example, under Alternative 2 some of the NADIN IA 
links would be able to absorb the NAS-NAS traffic without an increase in capacity. Further, 
for those links that require an increase, capacity would be added in increments of 9,600 b/s, 
even though this may be well in excess of that required. This approach is generally 
practical, since the only significant cost difference between a 2,400 b/s and 9,600 b/s line is 
the cost of the modems required to interface the lines with the communications node 
equipment. 

With an evolving system such as NADIN, it is very likely that the excess capacity 
would ultimately be consumed in servicing other FAA requirements, just as the NAS-NAS 
traffic could consume some or all the excess link capacity provided under the Level IA 
implementation. Two basic approaches would be generally applicable for considering the 
costs associated with excess NADIN link capacities. These are: 

1. Marginal Costs - i.e, consider the full cost associated with increasing link 

capacity and consider any previously excess capacity as 
free. 

2. Pro Rated Costs - i.e., assume that all capacity available on a link would 

ultimately be used (regardless of NAS-NAS support 
alternative implemented). Then assign as a cost to 
NAS-NAS support only a pro rata share for the capacity 
expected to be used, be that on a previously existing line 
or a line to be added. 


For this analysis approach 1, marginal costing, has been adopted. 





D.3 TARIFFS 


A significant element in the costs for all five alternatives are the charges by 
commercial carriers for providing leased line service. For this analysis it is assumed that 
the Multi-Schedule Private Line (MPL) tariffs apply to both the NAS-NAS Network and the 
NADIN backbone network. Further, it is convenient to assume that all backbone nodes (the 
20 ARTCC.') are located in areas designated "Category A" under those tariffs. 

The MPL tariffs include four major categories of charges. These are: 

1. Station Terminal Charges, including a one-time installation charge of approxi¬ 
mately $57 per drop (i.e., $114 per point-to-point channel), and a recurring cost 
of $26.30 per drop per month; 

2. Fixed Charges of $51.72 per channel per month; 

3. Interexchange Mileage Charges, shown in Table D-l; 

4. Channel Conditioning Charges, including an installation charge of approximately 
$171 per drop, and a recurring cost of approximately $15.50 per drop per month. 

D.4 OTHER COST CONSIDERATIONS 


Most of the other cost considerations are pertinent only to the individual alternatives. 

Those that are of more general concern are indicated below: 

1. Modems required at each end of 9,600 b/s lines cost approximately $8,500 
apiece. 

2. The only significant cost associated with channels between a collocated N'ADIN 
switch and concentrator is the cost of modems or other interface adaptors. Such 
equipment will generally be much less expensive than modems required for the 
long distance leased lines. For this analysis, however, two $8,500 modems are 
assumed to be required for each such channel also. 

3. Software development will cost approximately $150 per instruction. 
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MILES 


COST/MILE/MONTH 


0 - 15 
16 - 25 
26 - 100 
100 - 1,000 


$1.89 

1.58 

1.18 

.69 


over 1,000 


.42 


1. Rates shown are based on MPL tariffs for channel 
between two Category A locations. 


2. Example 

calculations - 

250 mile 

channel: 

15 

miles 

<a 

1.89 = 

$28.35 

10 

miles 


1.58 = 

15.80 

75 

miles 


1.18 = 

88.50 

150 

miles 


.69 = 

103.50 

TOTAL 250 

miles 


= 

$236.15 


TABLE D-l: INTEREXCHANGE M ILEAGE RATES 
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